WebGL Framerate Tips

I saw at least one other person asking for a thread on this because they'd had a hard time finding anything to make much of an impact on performance. Most of our tests are geared toward the low-end (ARM-based Chromebooks) because anything better than that is generally getting a sufficiently high frame rate without optimization.

• 50% increase from switching large, reflective water into just refractive.
• Next we found that cutting down on geometry was the only other thing that really helped--and we had to cut WAY down for it to have an impact. Essentially had to crank in the clip plane as a last ditch emergency effort.
• Curiously, when we were running cinematics, we found that the FPS sped up dramatically over the course of the first 15 seconds. Again, we only noticed this on the really low-end ARM chromebooks, where every little bit of performance boost matters. It would ramp up from 1 fps to about 15 fps. I suppose it might be happening during normal gameplay, but we don't notice because framerate isn't as critical.
• Turning off all kinds of particles for smoke or rain or clouds or dust or splashes only made a negligible improvement.

Looking forward to any other tips or insight folks are able to glean.

 

Here are some of my findings whilst wrestling with a very low end chromebook (ASUS/Arm Mali GPU):

• An easy way to show the framerate is to go to "chrome://flags/" in the address bar and enable "fps counter"
• Use 'chrome://gpu/' to see a list potential driver related headaches you may be heading towards
• We were able to get very, very, simple scenes to render at 50+ fps (but they were very simple NGUI background, handful of buttons, no 3D geometry)
• Didn't notice number of draw calls having a significant impact
• During profiling it seemed that the CPU was the bottle neck but we don't really do anything with the CPU and a lot of this time seemed to be coming from unity preparing objects to be renderer (sorting them into batches, etc...). I can't remember the names of the function calls though.
• At is worst the app could hit 6fps but under normal conditions it would hover around 15 - 20fps (20fps didn't seem too bad strangely, not smooth, but responsive enough that you didn't want to tear your hair out)
• Fill rate doesn't seem to be an issue (unlike most mobile devices)
• We had some terrains in there, I ended up reducing all the foliage detail to zero (I think think had a noticeable impact). Toy'd with the idea of replacing them with static meshes but during my experiments I had everything mapped to a hotkey so I could selectively turn everything off one by one and examine the difference. This is how I came to the conclusion that nothing had a significant performance effect. Things would change by 1or 2 fps.
• We'd occasionally get a memory crash whilst parsing the initial javascript but I think this tell chrome to cleanup and free its resources because it would always work the 2nd time. Actually memory seemed to not be an issue which I found surprising.

 

In case it's helpful for reference, here's a screenshot--this runs at 10 FPS on an ASUS Chromebook with a Rockchip ARM. On one level, I'm super impressed that this cheap of a computer can run it this well. The zero-install option is going to be fantastic for us

 

Here's the interesting one. If we jump straight into this opening cinematic the FPS is 1 or 2. But if we wait 13 seconds, it jumps up to around 15--just by sitting there.