[Webkit-unassigned] [Bug 250314] [WPE][WebGL][Canvas][Compositing] Threaded compositor may use a 3D canvas target FBO texture before the WebGL rendering has finished

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 11 10:34:23 PST 2023


https://bugs.webkit.org/show_bug.cgi?id=250314

--- Comment #5 from Loïc Le Page <llepage at igalia.com> ---
After rethinking about the whole issue I've reached those conclusions:

1- The cause of the issue is that the compositor uses the WebGL canvas target texture BEFORE all drawing commands of the canvas GL context have been executed by the GL server.

2- It is happenning with the EGL renderer on NVidia card and on Android. I haven't done advanced testing on WebKitGTK or with other 3D hardware. Indeed, it seems to work well with software rendering.

3- Independently of the 3D hardware, in the OpenGL/ES specifications neither glBindFramebuffer nor glFramebufferTexture2D guaranty any kind of implicit synchronization, so without explicit synchronization code the real behavior may be up to the drivers implementation.

Conclusion: if we want to ensure frame completeness in all situations we have to add our own synchronization code.

I can see two opposite approaches:

1- We compose only on a new frame, then somebody has to wait.

1a- Or the rendering thread waits for frame completeness before giving the texture to the compositor (this is my current approach until now), in this case we block the rendering thread until the frame is complete which can block other important stuff if the rendering thread is the same as the main thread. But we allow the compositor to follow the same pace as the fastest rendered canvas in the web page.

1b- Or the compositor thread waits for the frame completeness before using the WebGL canvas target texture, in this case the compositor pace is limited to the slowest rendering canvas in the web page and if there is a fastest rendering canvas some of its frames will just be dropped.

2- We compose whenever the compositor thread wants and we just ignore the canvas that have not a new frame complete at this moment. In this case nobody waits, but if a canvas target texture is not complete when the compositor is drawing, it will redraw the same previous frame for this canvas.

>From the implementation point of view, if GL fences are available all solutions 1a, 1b and 2 can be implemented. If fences are not available and only glFinish is available, only 1a can be implemented.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230111/0544c417/attachment.htm>


More information about the webkit-unassigned mailing list