[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 #9 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Zan Dobersek from comment #8)
> Comment on attachment 310260 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=310260&action=review
> 
> >>> Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:266
> >>> +        sceneUpdateFinished();
> >> 
> >> How can this occur? renderLayerTree() returns early at the beginning if the scene is not active. If it is active, the function then executes serially, which should make it impossible for any task to be scheduled on this thread that would make the scene inactive.
> > 
> > Because invalidate happens in the main thread.
> 
> That's doing unsafe cross-thread modifications then.

We should probably make m_isActive an Atomic<bool>, yes.

> >>> 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.

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