[CoordGraphics] Revalidate need for 'coordinated update completion' in ThreadedCompositor

• Component: New Bugs
• Status: RESOLVED FIXED

[Zan Dobersek]

In ThreadedCompositor, we enforce what we call a "coordinated update completion with the client" when any platform layer has been updated (WebGL or GStreamer media). This means that the following frame is not "complete" until a main-thread callback is dispatched in which the client (i.e. CompositingCoordinator and the LayerTreeHost that owns it) is notified of the completion of that frame. Any further flushes and updates are blocked until that callback is dispatched.

As far as I remember this solved various rendering glitches in WebGL content that was re-rendered as the previous rendering results were still in the process of being composited. This is not an ideal solution, but it works -- at the expense of the callback scheduling on the main thread, which can be a problem.

Ideally we'd find and use a different solution that allows correct WebGL content presentation without this additional coordination step.

This report originates from bug #188693.

[Miguel Gomez]

I've been testing the rendering on wkgtk and wpe and seeing whether this "coordinated update completion" was required. In a general case, this path is followed only when the WebGL layer is created. After that, during WebGL rendering, there aren't platform layer updates (new buffers come through the proxy) so there's no such coordination really happening.

I've run several WebGL tests, both with wkgtk and wpe and the WebGL rendering is not affected if this change is removed, so I'll send a patch to do so and simplify the code.

[Miguel Gomez]

Created attachment 364532 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 364532 [details]
Patch

Clearing flags on attachment: 364532

Committed r243865: <https://trac.webkit.org/changeset/243865>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/49599825>