[Webkit-unassigned] [Bug 154444] [ThreadedCompositor] Opening the inspector in a window causes a crash.

[bugzilla-daemon at webkit.org]

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

--- Comment #15 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #14)
> Comment on attachment 281169 [details]
> Updated patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=281169&action=review
> 
> > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:66
> > +        m_scene->setActive(handle);
> 
> !!handle converts better (i.e. cleaner) to a boolean value.

Ok.

> > Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:69
> > +        ensureGLContext();
> > +        updateViewport();
> 
> It's not clear from the change log -- are these calls required in case of
> handle being null?

Ok, I'll update the ChangeLog. When the handler is null, ensureGLContext actually destroys the current cotext, to ensure any pending or further operation on the compositing run loop returns early in !glContext(). The updateViewport is to ensure we re-schedule a display on next frame for the new handle, since we have cancelled any previous one. It's probably not needed in the case of null handle.

> > Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp:202
> > +    scheduleLayerFlush();
> 
> Why cancel and then re-schedule the layer flush? Just re-scheduling should
> be enough.

Since setting the new handler on the compositor is sync now, I want to make sure we cancel any scheduled layer flush before actually changing the handler, and then scheduling a new one once we have the new handler. That's exactly what we do in LayerTreeHostGtk too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160614/3503b462/attachment.html>