[Webkit-unassigned] [Bug 228673] New: [GPU Process] RemoteImageBufferProxy::flushDrawingContextAsync() should always append FlushContext to its DisplayList

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jul 30 17:27:15 PDT 2021


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

            Bug ID: 228673
           Summary: [GPU Process]
                    RemoteImageBufferProxy::flushDrawingContextAsync()
                    should always append FlushContext to its DisplayList
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Canvas
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com
                CC: dino at apple.com

Appending FlushContext to the DL makes GPUProcess do two things:
1. Flushes the backend context.
2. Sends a DidFlush message back to the WebProcess.

One of the callers of RemoteImageBufferProxy::flushDrawingContextAsync() is RemoteImageBufferProxy::flushDrawingContext() which assumes FlushContext is added all the times and this is why it waits for 3 seconds and then gives up. But flushDrawingContextAsync() adds FlushContext only 'if (!m_drawingContext.displayList().isEmpty())'. The opposite can happen very often since clearDisplayList() is called from flushDrawingContextAsync() itself. So we can waste three seconds waiting for a message that will never be received because the DisplayList is empty.

If 'm_drawingContext.displayList().isEmpty()' is true, appending FlushContext may not be needed. But we do not know for sure if the GPUProcess is applying or will be applying items from the SharedBuffer for this ImageBuffer. We need to ensure all the items are processed and we may be waiting for a DidFlush message. So the solution is to make RemoteImageBufferProxy::flushDrawingContextAsync() append FlushContext to its DisplayList always.

-- 
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/20210731/2f6c67b6/attachment-0001.htm>


More information about the webkit-unassigned mailing list