Chrome and SVG (Raphael), trouble with drawing "off-screen" - javascript

I'm working on a prototype system which will act as a proof of concept that an existing system can be made a lot more interactive.
It basically emulates our main software package but over the internet using JSONP requests to update a load of images and Raphael vectors to make it look like everything's running.
I'm having trouble on Chrome however with Raphael not drawing vectors "off-screen". What I mean by "off-screen" is that the main app runs through an iframe as it relies on cross-domain long poll comet through AJAX to get communicate back and forth. Below is an image demonstrating what I mean.
Here I've scrolled a long a little bit in the iframe to look at the bits "offscreen" and you can hopefully see that the grey arrows aren't rendered. I've used Chrome's developer tools to highlight over the SVN tag, showing that it's only given 450px by 810px to the SVG tag, which is the same size allocated for the iframe.
It's worth pointing out that it renders fine in Firefox. Any ideas?

I've had a similar problem and found a bug report for the WebKit project that seemed related:
https://bugs.webkit.org/show_bug.cgi?id=64823
According to the comments, it's a bug in the rendering engine and there's no workaround aside from losing the iframe or resorting to other means of scrolling the SVG viewport (like moving all the elements within the SVG element).
On the upside, version 16.0.912.21 has been released to the beta channel today and it seems that the bug has been fixed. I've also checked the latest chromium build (17.something) and the bug hasn't resurfaced. I'm guessing the fix should find its way into the stable channel in a couple of weeks.

Related

How to view 3d html5/css3/native javascript page stereoscopically on mobile?

Short version: Kieth Clark has a 3D html fps shooter demo. It uses 3d tansforms on html5 elements to produce a 3D world experience. It is not VR. Is there an API to view it stereoscopically?
I have a similar engine. I came up with a way to view it stereoscopically using Cardboard-style viewer, 3D TV/Monitor, or red/cyan anaglyph glasses. I had to use a pair of iframes, however, and load a copy of the "world" document into each frame, however.
This doubles the load on the gpu, however, requires duplicates of all changes to "the world" for both iframes, and workarounds for focusable items such as textareas. This all works great, but diminishes the capacity for detail without RAF noticably slowing down and getting jumpy. Especially true in Firefox on mobile, and of course there is also the added problem of security limitations on iframes.
If theres an API to just view and control a 3D html5 page in stereo without explicitly duplicating everything that would make things a lot simpler and more efficient.
I'm using a Google Chrome on Galaxy Note 3 as my standard-level target-device, if anyone needs to know.
Long version (old):
I have a 3d game I'm writing with native html5/css3/javascript. It is primarily for mobile and already contains a fully-functional camera system with the ability to zoom in or out of first-person, second-person, overhead etc, rotate the yaw and pitch of the view, as well as location on the map around the avatar, etc. Is there an easy way to view it stereoscopically? It will be embedded in an Android app, or at least accessed through one, or through Chrome as a web-app. I thought Chrome Dev with VR Shell would be a possibility to try it out and hopefully integrate into an app eventually. Not having luck with that yet. Theoretically, I just need to be able to view an ordinary html5 page that has css3 3d transforms. For example, if you had a 3d cube made of divs or whatever, to view it with two points of view, one for each eye, without changing anything in the page itself. Basically, if you could view anything 3d in the page stereoscopically, much like the VR Shell sounds like, it should work. All I seem to come up with is how to turn on the flag in Chrome Dev, but I'm not seeing anything to actually activate it. It's been fully restarted etc. The page is already 3d and fully-functional with orientation control in first-person or otherwise. All I seem to find are how to turn it on or about 3d videos. Can this be done in Googles VR libs for Studio without using all the other stuff? I just need the second eyeball.
Ok. Was hoping an api existed for this, but my solution was to make a parent document with two iFrames and load the doc with the 3d tranforms into both iframes. Then offset the perspective-origin in each about 1% (i.e. 49% in one and 51% in the other). Worked great without added mods using device orientation, but obvi not for mouse control. Ideally, both iframed documents should be controlled from js in the parent doc. Downside is you have to control two objects for every change, and complications arise if you have inputs or textareas that take exclusive focus. Fixed all that, but this is the down-low version of the solution.

How to find out what is affecting the elements on a page?

I am currently building a site. When I refresh the page (as seen below), the two boxes with the brown outline start out at what seems to be 100% width, but then they re-size after about 1-2 seconds, and there is a small gap on the right hand side.
I'm pretty sure this isn't happening via the CSS, as there is a delay and I've looked through it all myself and can't find anything.
I am using Google Chrome's Developer Tools - is there any way that I can view any related JavaScript being ran on refresh that may be affecting these elements?
You can use a chrome extension to quickly turn off javascript. If the problem dissappears, you know that javascript is causing the problem. If the problem is still there, then it is a CSS issue (which I think is the case, but we can't solve that for you as you didn't provide the code).
here is a link to the javascript switcher extension:
https://chrome.google.com/webstore/detail/quick-javascript-switcher/geddoclleiomckbhadiaipdggiiccfje

Chrome App Poor Performance

I am developing a Chrome App which is based on the same code as the normal web based version. It's a web-audio app so quite performance critical for timing purposes.
I have noticed whilst holding down the mouse button within the app and wiggling it around, performance drops significantly, enough to mess up the timing. This issue does not occur in the ordinary browser based version which is running the same code.
I have recorded the activity with the Chrome developer tools and the only thing I can spot that does not happen with the browser based version is a function call to updateAppWindowProperties - which is a built in Chrome App function.
I have attached a screenshot of the dev tools recording where you can see 3 big spikes in the activity, these are the bits where I am holding down the mouse button and moving it around.
Anyone know what the cause of this could be, is it something to do with the Chrome App checking the window size?
It seems to have been fixed by reducing the number of css classes. I had a LOT of classes that were used only for jquery selectors, I changed them to data attribs and that seems to have fixed the performance issues.

What's the workflow for determining if a bug is the browser's fault, or my own?

I'm working on a project right now and I've written some code using Pixi.js that produces strange results in Google Chrome. Specifically, drawing a sprite with a texture seems to be creating a strange issue where multiple loaded textures are drawn on top of each other, when only one was requested. (e.g. I say "load a cat, load a dog, draw a cat" and for some reason I see a cat on top of a dog.)
I don't see this issue in Firefox or in Safari. I'm not sure if this is my own bug, a bug in Pixi.js, or a bug in the browser. It doesn't really matter, because that's not really what this question is about-- I'm just telling this story for context.
My question is: what is the general workflow for determining whether or not a bug is my own, or a problem with the browser? Is there some standard process for debugging browsers?
I'm not sure if there's a standard process, but from my experience with PIXI, I've found that when the bug is in my code it generally shows up in all the browsers.
Browsers often have differences in HTML/CSS, but they seem to display the canvas the same. So if the issue is with the general layout of the entire canvas or other DOM elements, I would assume it's a browser issue.
But if the problem is with rendering a PIXI component on the stage, it is more likely either a PIXI bug or a bug in your code. Keep in mind PIXIjs renders using WebGL if available, otherwise it falls back on the HTML5 canvas. So I would check that first by turning WebGL on and off within the same browser and see if it makes a difference.
If you're curious to know why your dog didn't render correctly, go ahead and post some code :)

CSS: Sub-menu expanders ([+]/[-]) jump up and down upon open and close due to a CSS porting glitch

On this website (tested in close-to-latest
Opera, Firefox and Google Chromium on Mageia Linux 3 Cauldron and on Firefox on my Arch Linux VM), the expanders/[+] signs of the navigation menu on the left get shifted a little
upwards and downwards when the sub-menu is expanded/collapsed. That's not the case if the expander in question the last one in the sub-tree (for example, under "Humour" →
"Recommendations").
Why and how can it be avoided? Is it because of the different character in the text? I tried setting it to monospace - it did not help.
It works fine here, but the CSS and generated
DOM are different.
(Note: this is my permanent site while this is the
temporary/testing one. They look mostly the same now, but do not use exactly the same markup, CSS and JS.)
The problem is that I'm trying to make jqTree look more like what I had in the old
jQuery Treeview, and it won't cooperate. I spent an entire day on it yesterday,
and while I fixed many problems, I still have this one.
I tried using Firefox's Firebug, Opera's Dragonfly, and the equivalent tool in Google
Chromium has, but I lack the necessary skills to understand what goes wrong.
It appears that the jQuery Treeview authors tried to optimise performance by using a single image with a different background-position which makes it hard to debug, and I didn't get rid of it yet.
Any pinpoint to the problem, and/or a fix will be appreciated.

Categories

Resources