[Webkit-unassigned] [Bug 273317] New: [GTK][WPE] Main thread can't start rendering the next frame until the previous one is composited

[bugzilla-daemon at webkit.org]

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

            Bug ID: 273317
           Summary: [GTK][WPE] Main thread can't start rendering the next
                    frame until the previous one is composited
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: magomez at igalia.com
                CC: bugs-noreply at webkitgtk.org

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.

-- 
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/20240426/83770e5e/attachment-0001.htm>