Bug 273317 - [GTK][WPE] Main thread can't start rendering the next frame until the previous one is composited
Summary: [GTK][WPE] Main thread can't start rendering the next frame until the previou...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Miguel Gomez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-26 05:56 PDT by Miguel Gomez
Modified: 2024-05-06 04:43 PDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miguel Gomez 2024-04-26 05:56:26 PDT
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.
Comment 1 Miguel Gomez 2024-04-26 06:11:39 PDT
Pull request: https://github.com/WebKit/WebKit/pull/27800
Comment 2 EWS 2024-05-06 04:43:06 PDT
Committed 278399@main (9191148390c2): <https://commits.webkit.org/278399@main>

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