Chrome lags on cursor changes

[jonathanolson]

FPAF and other sims show this.

[jonathanolson]

Also a problem in ESPB during animation.

[jonathanolson]

Didn't find any issues in Chromium bug tracker.

[jonathanolson]

I found no direct solutions or workarounds, and didn't find any public reports of this in Chrome (Googling, or in the Chromium issue tracker).

It seems that the style and layout computations are re-done even if we add an overlay meant just for the events.

Notably in the screenshot below, this is triggering over all of the nodes in the SVG tree whenever the cursor changes. I'd highly recommend combining many line/path elements into a single path (see GridNode, GaugeNode), and minimizing the number of nodes (it's reflowing the invisible ones also). I see ToggleButtonDeprecated with 4 copies of things. The Scene when loaded in the 1st tab has ~1320 nodes in the tree (including all screens), so I'd recommend testing with the add/remove child for screens instead of visibility toggles to see if that helps.

Also, we probably want to open a Chromium issue for this.

[samreid]

I tried launching ESPB with ?standalone, and it seems like the problem reduced by about 70%, so I think @jonathanolson hypothesis is correct. This seems like another opportunity for WebGL to solve the problem, since there will be no reflows.

[jonathanolson]

Also, liberal use of Canvas for things that don't need to be redrawn often may also help improve this.

[samreid]

Is there an easy way to get a DAG size from scenery? If that is an important performance measure, perhaps we should have a straightforward API to get it?

[samreid]

One way to see the DAG (as a tree?) is by using simScene.popupDebug() in the console.

[samreid]

Perhaps counting the lines in simScene.popupDebug() is a good way to "weigh" the scene graph.

I see the following counts:

1305 lines in the original version.
580 lines when using 'setChildren' instead of 'setVisible'
546 lines when using 'setChildren' and no gridnode
538 lines when using 'setChildren' and no gaugenode ticks
532 lines when using 'setChildren' and no ToggleNodeDeprecated.
456 lines when using all changes above

[samreid]

@jonathanolson any suggestion how to directly & automatically measure the dom reflow time using code? Or is the chrome developer tool the best way to do this?

[jonathanolson]

I just made a recursive function to count in the console, but I don't mind adding a function to Node to count.

[jonathanolson]

I don't know of any way besides checking in the dev tools to actually view it, I'd just qualitatively test performance.

[pixelzoom]

This should be reported to the Chrome team.

[samreid]

I tested removing all of the svg elements from the otherwise webgl-rendered ESPB and the problem went away. So perhaps rendering things in WebGL could solve this problem.

[samreid]

Chrome 38 came out today, and this problem just got a whole lot worse. 😞

[samreid]

This issue seems to go away if I get rid of everything except for the WebGL canvas (But I have to get rid of the navbar too). This suggests that going to WebGL could solve this problem, but we would have to use WebGL for the navbar as well as the sim screen.

[jonathanolson]

Please see tests/browsers/chrome-cursor-test.html. Reproduces the slowdown with just a static SVG state.

[pixelzoom]

@jbphet says: tested this in Arithmetic recently, and it may be worse with scenery 0.2.

[jonathanolson]

Timeline of FPAF shows that the cursor update triggers recalculation of styles (more expensive) and layout (less expensive). Compositing looks like a significant (dominating?) factor unless I'm reading the plot wrong (I'll read up on the tools a bit):

We could consider some creative (hacky) ways of not triggering style recalculation but still changing the cursor (e.g. maybe creating divs for each cursor type and change their stacking order might work).

Will probably need to bring back the original cursor toggling test page.

[jonathanolson]

#337 should help with this.

[jonathanolson]

Unable to reproduce the cursor issue on Chrome 45 (Win 7), anyone else (@pixelzoom, @samreid, @jbphet, @aaronsamuel137) noticed this in sims recently?

[aaronsamuel137]

I can't seem to reproduce it either. I remember a slight stutter in color-vision when the cursor changed and the photon view was present. Doesn't seem to happen anymore.

[pixelzoom]

I have never seen this issue.

[jonathanolson]

Can't reproduce on other platforms. Closing for now.