Performance on iPad 2 Sluggish when All Checkboxes Active

[arouinfar]

Test device: iPad2
Operating System: iOS 7.1.2
Browser: Safari

Problem description:
When turning on all four checkboxes, there is a very noticeable lag in the playback speed of the sim. This occurs when the skater is on a pre-built track or one made in the playground screen. The playback speed seems to reduce by about a factor of 2 if timing the skater with a stopwatch.

Steps to reproduce:

1. Open the Intro Screen
2. Place skater on highest point of track (to maximize the speed)
3. Turn on all four checkboxes (Pie Chart through Speed)

The sim speed will become noticeably sluggish.

Severity:
This is a very noticeable performance issue that should be addressed.

Screenshots:
I have a screen capture clip of this issue from an interview, but for IRB reasons I don't think I should post it publicly to GitHub. Email me if you would like to see the clip.

Troubleshooting information (do not edit):
Name: Energy Skate Park: Basics
URL: http://www.colorado.edu/physics/phet/dev/html/energy-skate-park-basics/1.0.0-dev.61/energy-skate-park-basics_en.html
Version: 1.0.0-dev.61
Features missing: fullscreen
User Agent: Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53
Language: en-us
Window: 1024x671
Pixel Ratio: 1/1
WebGL: disabled

[samreid]

I tested http://www.colorado.edu/physics/phet/dev/html/energy-skate-park-basics/1.0.0-dev.53/energy-skate-park-basics_en.html on iPad3 and compared to the latest version http://www.colorado.edu/physics/phet/dev/html/energy-skate-park-basics/1.0.0-dev.62/energy-skate-park-basics_en.html (on the 1st screen with all checkboxes checked). dev.53 runs much faster on iPad3 (somewhere around a factor of 2 faster?). I suspect the speed dropped when we switched to a fixed timestep model in order to attain reproducible physics, and that the frame rates are actually very similar.

I can look into this issue but we'll have to decide what an acceptable criteria is, and how long we can delay before publishing 1.0. I'll email @ariel-phet for feedback.

[samreid]

Using ?profiler and comparing times taken of each checkbox independently on the 1st screen, I see:
4ms pie chart
5ms bar chart
<1ms grid
~1ms speedometer

combining them in the sim:
9ms pie chart + bar chart
14ms pie + bar + speedometer
19ms all 4 combined

apparently there is some nonlinear interaction between the four items.

[samreid]

By the way, WebGL would very likely solve these performance problems. We could publish now (or soon), then republish once we have a WebGL renderer.

[samreid]

By the way, canvas renderer with no features enabled is about 10 frames per second (very sluggish!)

[ariel-phet]

@samreid, I think this is worth 1-2 hours of investigation to see if the severity of the issue can be reduced (perhaps also get @jonathanolson to help out). Please investigate and then lets talk when you have more information. The nonlinear interaction between the items makes me suspicious, but we definitely don't want to change the model/physics now to address this sort of issue since we seem to be in a fairly stable place.

[samreid]

@jonathanolson and I worked on this for around 2 hours and discussed:

1. running the model at 2x speed in some cases, but that could be difficult to make it smooth and may even make the sim run slower since the sim is CPU intensive.
2. a layer split between the active and inactive layers, and it did not seem to help (but we kept this change since it did not seem to hurt performance either)
3. removing the stroke from the pie chart buys 4fps but looks pretty horrible. The stroke and inner lines would have to be drawn anyways.
4. can do the override for Path.computeShapeBounds, since the bounds for the pie chart and bar charts are never used. This is something I should still do, but not expected to attain a huge benefit
5. we created a version that runs the model at dt=2.0/60 instead of 1.0/60 and only update every other frame. On iPad3, this makes the performance significantly less smooth (though just as fast) when no checkboxes are selected, and the speed is almost completely maintained (6.9 second period vs 7.3 second period or so) when the checkboxes are selected. However, I am skeptical to make the default performance noticeably slower to solve this problem, and it would introduce complications about enabling this logical branch only for iPad (or other similar platforms?)

[samreid]

I pushed the last idea to the branch 'skipframes'

[samreid]

By the way, @jonathanolson said this isn't the best sim for WebGL since many of the bounds/shape computations have to be done on the CPU anyways.

[samreid]

It seems like using

bar.computeShapeBounds = function() {return new Bounds2( 0, 0, 0, 0 )};

in BarChartNode

and

kineticEnergySlice.computeShapeBounds = function() {return new Bounds2( 0, 0, 0, 0 )};
potentialEnergySlice.computeShapeBounds = function() {return new Bounds2( 0, 0, 0, 0 )};

seems like it increases the average frame rate from 27fps to 31fps on iPad3. I'll keep this change if it doesn't look like those bounds are used.

[samreid]

I tested and did not see any differences so I pushed the above change.

[ariel-phet]

@samreid just looked at latest push on ipad2 with @arouinfar said it looked better. Slowing down is still noticeable but less dramatic. Might be acceptable, we can discuss.

[samreid]

Comparing to my earlier (high variance) numbers, it looks like rendering with all checkboxes on is costing about 34ms/frame instead of 36ms/frames, so it seems the above optimizations have sped things up by about 5% or so.

[samreid]

I tried shrinking the bar chart + speedometer and moving them toward the middle to see if phetsims/scenery#270 was being triggered, and the performance did not seem affected.

[samreid]

This problem will be solved for iOS8 devices, thanks to WebGL

[samreid]

@jbphet reports the following for iPad2/iOS7

58fps average with all checkboxes off
40fps average with all checkboxes on

In my opinion, this is significantly better than before, and acceptable for publication.