[Webkit-unassigned] [Bug 172167] [Threaded Compositor] SHOULD NEVER BE REACHED in WebKit::CompositingRunLoop::updateCompleted

[bugzilla-daemon at webkit.org]

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

--- Comment #11 from Zan Dobersek <zan at falconsigh.net> ---
Comment on attachment 310260
  --> https://bugs.webkit.org/attachment.cgi?id=310260
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=310260&action=review

>>>>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:292
>>>>> +            return;
>>>> 
>>>> m_coordinateUpdateCompletion should be set here, but to false if m_inForceRepaint is false as well.
>>> 
>>> That happens, because it doesn't return early.
>> 
>> I'm saying it should be set regardless of the value of m_inForceRepaint. But if m_inForceRepaint is false, it should be set to false.
>> 
>>     bool coordinateUpdate = m_inForceRepaint && std::any_of(...
> 
> That's what caused the timeout, and I suspect bug #172027 too. If we change coordinateUpdate for the force repaint, the frame is never completed. If the state is PendingAfterCompletion, we won't process more updates. So, what we do here is handling the force update like it didn't happen, to ensure frame updates continue working as expected.

When do you expect a forced updated to be finished? And do you expect the DisplayRefreshMonitor callback to be scheduled for forced updates?

You also don't have any guarantee that there is a scene state update pending that would be executed during a forced repaint, meaning m_clientRendersNextFrame isn't necessarily flipped to true, which would end up not scheduling a DisplayRefreshMonitor callback in sceneUpdateFinished() that would complete the update.

-- 
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/20170517/dc5ced6b/attachment.html>