WebGL app like crystalskull runs very slow(<1 fps) on my device(unagi) which hardware composer is unavailable. after some investigation, I found that when turn on sForceReadPixelsToFence or call glFinish() at SharedSurface_Gralloc::Fence() function improved performance greatly. I tried KHR_fence_sync extension here but did not help a lot. Is this normal behavior?

this bug https://bugzilla.mozilla.org/show_bug.cgi?id=863223 changed CanvasClientWebGL::Updated() from sync to async operation. I found this change would let WebGL send drawcall to GPU continually and keep utilization of GPU is high. This would cause Compositor thread unable to composite because GPU is too busy. after changing this function to sync operation. Crystalskull rendered smoothly now on unagi device. Is there any reason CanvasClientWebGL::Updated() is async operation? If this function should be async operation, Does it have any mechanism to prevent WebGL keeping produce frames which Compositor even doesn't render it?

(In reply to Morris Tseng [:mtseng] from comment #1) > Is there any reason CanvasClientWebGL::Updated() is async operation? With OMTC it improved frame rates by freeing up the content thread. > If this > function should be async operation, Does it have any mechanism to prevent > WebGL keeping produce frames which Compositor even doesn't render it? We have such a mechanism in SurfaceStream_TripleBuffer_Async, yes. I guess B2G is using SurfaceStream_TripleBuffer which has no way of guarding against this. My suggestion would be to set a flag in CanvasClientWebGL::Update() when we are out of process that makes us then do a synchronous transaction later on in CanvasClientWebGL::Updated().

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #2) > (In reply to Morris Tseng [:mtseng] from comment #1) > > Is there any reason CanvasClientWebGL::Updated() is async operation? > > With OMTC it improved frame rates by freeing up the content thread. > I had a question here. content thread will have better performance output with async way. But how to make sure the buffer synchronization between content and compositor thread, otherwise you might see some tearing during composition. > > If this > > function should be async operation, Does it have any mechanism to prevent > > WebGL keeping produce frames which Compositor even doesn't render it? > > We have such a mechanism in SurfaceStream_TripleBuffer_Async, yes. I guess > B2G is using SurfaceStream_TripleBuffer which has no way of guarding against > this. My suggestion would be to set a flag in CanvasClientWebGL::Update() > when we are out of process that makes us then do a synchronous transaction > later on in CanvasClientWebGL::Updated().

(In reply to peter chang[:pchang] from comment #3) > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #2) > > (In reply to Morris Tseng [:mtseng] from comment #1) > > > Is there any reason CanvasClientWebGL::Updated() is async operation? > > > > With OMTC it improved frame rates by freeing up the content thread. > > > I had a question here. content thread will have better performance output > with async way. > But how to make sure the buffer synchronization between content and > compositor thread, otherwise you might see some tearing during composition. > > > > If this > > > function should be async operation, Does it have any mechanism to prevent > > > WebGL keeping produce frames which Compositor even doesn't render it? > > > > We have such a mechanism in SurfaceStream_TripleBuffer_Async, yes. I guess > > B2G is using SurfaceStream_TripleBuffer which has no way of guarding against > > this. My suggestion would be to set a flag in CanvasClientWebGL::Update() > > when we are out of process that makes us then do a synchronous transaction > > later on in CanvasClientWebGL::Updated(). I found OMTC within one process did some synchronization. But async update within cross processes without synchronization caused the problem. http://mxr.mozilla.org/mozilla-central/source/gfx/gl/SharedSurfaceGL.cpp#183 mtseng, please help to fix this issue on b2g.

We need to figure out how to do this cross-process sync. We had a plan back in the Taipei rendering work week, and it's still the right eventual one (tie in to the enqueue/dequeue native buffer functionality). For now, adding explicit finish is possible, but it will also hurt performance. We should probably analyze performance of a number of webgl apps with and without that finish; it might not be a bad thing on lower end devices.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6) > We need to figure out how to do this cross-process sync. We had a plan back > in the Taipei rendering work week, and it's still the right eventual one > (tie in to the enqueue/dequeue native buffer functionality). As I recall, this seemed relatively straightforward when we talked about it. Someone from Taipei was going to work on it, even, I thought? It definitely is the preferred solution, IMHO.

CJ, was this Peter, perhaps related to bug 901225?

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #7) > (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #6) > > We need to figure out how to do this cross-process sync. We had a plan back > > in the Taipei rendering work week, and it's still the right eventual one > > (tie in to the enqueue/dequeue native buffer functionality). > > As I recall, this seemed relatively straightforward when we talked about it. > Someone from Taipei was going to work on it, even, I thought? It definitely > is the preferred solution, IMHO. This path depended on implementing the missing pieces of SurfaceFlinger (IIRC) in Gonk, and making a specialization of SurfaceStream which uses that.

Thanks Jeff. Let's go after this for 1.3 then.

We should confirm that HWC is always available and in use for all 1.2 builds, including developer builds.

By Bug 917444 fixed, WebGL performance during OpenGL composition should become better.

By Bug 917444 fixed, crystalskull runs 15-18 fps on master unagi.