Bug 273317 – [GTK][WPE] Main thread can't start rendering the next frame until the previous one is composited

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Miguel Gomez]

In many cases the compositor thread can be looping constantly, composing frames without the intervention of the main thread (a video or an animation running in the main thread). In other cases, the main thread will be the one requesting compositions because there's new content rendered to be displayed. And in most of the cases there will be a mix of both things happening at the same time.

Every time a new frame is composed, the main thread is notified by the didRenderFrame call, but at the moment we can't distinguish whether the composed frame was requested by the main thread or not. This is important because the main thread needs to wait until the frame it rendered has been composed before starting to render the next one. With the current implementation, every didRenderFrame causes the main thread to render the next frame, which causes glitches.

We need a way for the main thread to know whether the composited frames were requested by the main thread or not.

[Miguel Gomez]

Pull request: https://github.com/WebKit/WebKit/pull/27800

[EWS]

Committed 278399@main (9191148390c2): <https://commits.webkit.org/278399@main>

Reviewed commits have been landed. Closing PR #27800 and removing active labels.