On platforms where we can't use the compositor to wait on the webgl we would like to add a frame of delay to let WebGL content resolve. Right now we just wait on the fence and run the CPU/GPU in lockstep. If we're using an async transaction we can hold off the transaction and delay it until the next frame if it has a WebGL edit and the transaction is asynchronous.

Depends on patches from bug 1066280

Implementing this on top of bug 1066280 is the right thing to do. I have a prototype that works on Windows. We can render content where the game logic takes 16ms with a non trivial load on the GPU. http://people.mozilla.org/~bgirard/webgl-tweak.html On my desktop machine with 15.8ms, 300 trig: Nightly: 36 FPS +-1 Prototype: 60 FPS solid

This delay transaction are now working. I couldn't see any race conditions. This is fencing properly. I'm still a 2x speed improvement for the case where the GPU rendering time == rAF time (and the times are non trivial). In my demo with 32ms CPU and 60k we get 15 FPS on nightly, 28 FPS with the patch.

Comment on attachment 8490429 [details] [diff] [review] patch v2 (rebased + fixes) Review of attachment 8490429 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/client/CanvasClient.cpp @@ +464,5 @@ > // Use the new TexClient. > mFrontTex = newTex; > > forwarder->UpdatedTexture(this, mFrontTex, nullptr); > + GetForwarder()->DelayFrame(mFront); Self note: Only do this if mFront is a angle surface.

Still need to work out the details of IMMEDIATE_UPLOAD && DEALLOCATE_CLIENT. I'd like feedback on the overall approach before I start fixing the individual failures.

WONTFIX for now. It's not a great solution but it's a viable candidate if other solution don't pan out. Basically it's our backup plan.