Email from kbr@ to PlayCanvas:
-------

1. Recorded a timeline from DevTools connected to a Nexus 5X and examined some of the long frames.
(anonymous function)
update
updateClientRect
getBoundingClientRect
Recalculate Style ... Layout

You should *never* be triggering a style recalc or layout in your game at run time. Do you know where this might be happening in your engine? Could it be a side effect of not calling preventDefault on certain event types, so that the browser's trying to initiate a scroll or other kind of operation when you receive your touch events? Or is part of your display HTML? Can you rewrite this so it's rendered into your WebGL canvas?

2. On several of the long frames I see the following stacks being expensive:
update
updateCollisions
fire
Environment.onPlayerProgress
Environment.fillVisibleCells
Environment.fillCell
Environment.isCellVisible

In a couple of cases I saw these taking 11.74 ms and 15.68 ms. These are most of a frame time and will surely cause jank. What are the data structures that these are updating? Have you profiled them in more depth? Are you seeing JavaScript object allocation as a major cost in your game?

3. The top-level "render" call seems to be taking quite a long time on the long frames. Examples: 12.84 ms, 13.22 ms, 9.72 ms, 9.44 ms. Have you profiled these to see where all of the time is going? There don't seem to be that many calls to WebGL, but I do see them reported as being pretty expensive (uniformMatrix4fv, bindBuffer, vertexAttribPointer, drawElements). If you can provide a smaller test case for the WebGL draw calls being expensive, we can look into it more. Do see https://github.com/kenrussell/webgl-animometer and  http://crbug.com/608576  though. Chrome Dev Channel on Android should contain this fix. (I did test with this version, though.)

4. On Windows, I see the following traces:
...
fire
Vehicle.onCrash
stop
addTime
drawQuadWithShader
setShader
link
getShaderParameter

and:

onUpdate
addTime
drawQuadWithShader
setShader
link
getShaderParameter

Shader compilation, linking, and especially querying are very expensive. They must be avoided at all costs at run time. Is it possible for you to generate and query all of your shaders during level loading time?

5. I see "Composite Layers" taking a significant percentage of frame time on Android. Talking with sunnyps@ and others to see if we can bypass this step for WebGL-rendered content on Android; this is being done now on Mac OS X. See  http://crbug.com/581777  , but see also  http://crbug.com/611805  which is a performance issue that needs to be addressed.

Reply from PlayCanvas:
----------

1. Yep, we know about this and we want to get rid of the call. To do this is actually rather difficult, but we want to look into it. getBoundingClientRect also generates garbage, so another reason to remove it from our render loop.
2. This is not part of the game I know about and the engineer that wrote it is off sick today. Should be back tomorrow. I'll ask him to look into it.
3. The render function does indeed take a long time. Most of the time is spent here. We set textures, uniforms, buffers and then submit the draw call. I'm not sure what we can realistically do to improve this part of the engine. But since so much time is spent in the draw function, a small change could generate a big win. Open to suggestions here.
4. Yes, a couple of shaders get compiled at runtime, but I believe only when you crash, not when gameplay is running. So they're not too serious.
5. This would be cool if something can be done Chrome-side.

We'd like to prototype overlays for WebGL on Android to see if the majority of the "Composite Layers" step can be removed. Need to gather a trace rather than use the Timeline view to see what is actually happening in there.

The game has now been officially released so feel free to make this bug public. Also, the current build can be found on this link now:

http://playcanv.as/p/y3ZFwtwW

To run the game 'predictably' although not completely deterministically, use this link:

http://playcanv.as/p/y3ZFwtwW?autoplay=true

Thanks. Making bug publicly visible.

Still need to compare Chrome to Firefox and Safari, possibly using Quartz Debug or other tools, and see whether the framerate is similar and whether Chrome's dropping frames.

We've talked with PlayCanvas recently and I've run the game on other browsers. At this point it looks like the stutters happen across browsers, and PlayCanvas has indicated that they feel they need to optimize the game itself more before asking the browser implementers to take a look. Consequently closing this as WontFix (not a bug) for the time being.