Slow performance on iPad 3 with second tab while adjusting fluid level

[pixelzoom]

1.0.0-dev.19

Is this with 'H3O+/OH- ratio' on or off?

[pixelzoom]

How are you adjusting the fluid level? Dropper? Water faucet? Drain faucet? All of the above?

[jonathanolson]

It seems to be slow while: a) Left-hand scale is open and the concentration is being changed (water faucet most noticeable, since the dropper adds slowly) OR b) Ratio view is on and the liquid is highly acidic or basic.

It was immediately noticeable by switching to the 2nd screen and turning on the water faucet, which hits condition (a).

[pixelzoom]

Does 'left-hand scale is open' mean 'Logarithmic' scale is selected?

[jonathanolson]

Seems about the same performance for 'Logarithmic' and 'Linear', just that it isn't collapsed (upper-right button is red with '-', ruler-like node visible).

[jonathanolson]

Initial profiling on the graph (if that's the name of the left ruler-like indicator) shows some SVG defs add/remove (any non-color SVG fill/stroke like gradients / patterns on objects that need self-paint changed currently do much more DOM manipulation than needed - will be fixed in Scenery 0.2), and general rendering performance hits.

Initial guesses of improvements:

1. If molecule icons aren't rasterized in an image, try using toImage (will be unnecessary in Scenery 0.2, would just need to indicate a desire to cache it)
2. Set layerSplit to isolate parts that don't change from parts that do change. Currently, the browser has to repaint/handle dirty rectangles for the beaker node/molecule count/volume indicator/beaker controls/pH meter/graph and indicators/reset all button - they are all in the same layer. A specific example: the ruler part of the graph doesn't have to be re-rendered while changing the pH, but since it's in the same layer AND visually overlaps, it will get repainted. The browser might determine the red and blue indicators are moving at the same time and create a union bounding box, redrawing most of that.
3. Consider CSS transforms for the moving indicators
4. If things like tick lines have to be rendered in the same layer, consolidate Path and Line elements into one Path where possible.

[pixelzoom]

@jonathanolson took a look at this and reported:

I'm finding no low-hanging fruit on the iPad 3 performance. Layer splitting seems to help, but since Chrome now (since ... 31?) allocates raster memory for every SVG block the size of the screen, it uses up too much graphics memory. replacing the gradient-molecule images with circles didn't have a noticeable impact. Should be improved with Scenery 0.2.

Since my design team has previously stated that iPad3 performance was acceptable, and I don't have an iPad3 for testing, I'm going to close this issue as 'will not fix'. If iPad3 performance issue are noted during RC testing, we can reopen this issue, or create new issues.

[jonathanolson]

Additionally noting slower performance on Nexus 7 (Android 4.4.2, Chrome 33) when the graph indicators are changing, and on the 3rd screen.

Probably "acceptable", but I'd definitely like it to be smooth.

[jonathanolson]

Similar performance profile on Nexus 7 Firefox 27.0 (Android 4.4.2), with a bit more slowness associated with the clipping (static ratio view particles during draining and hidden graph indicators is still a bit slow, but fast when ratio view is turned off).

If deemed necessary, in the future the "fake clipping" bit could help.

[pixelzoom]

To clarify… Is the slowness you're seeing being causes by turning the 'H3O/OH ratio' feature on? Or is performance sluggish with this feature off?

[jonathanolson]

For Firefox on Android, it's related to the feature being on, even if it's not changing the particle positions.