<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:zan@falconsigh.net" title="Zan Dobersek <zan@falconsigh.net>"> <span class="fn">Zan Dobersek</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [ThreadedCompositor] Opening the inspector in a window causes a crash."
href="https://bugs.webkit.org/show_bug.cgi?id=154444">bug 154444</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>zan@falconsigh.net
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [ThreadedCompositor] Opening the inspector in a window causes a crash."
href="https://bugs.webkit.org/show_bug.cgi?id=154444#c16">Comment # 16</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [ThreadedCompositor] Opening the inspector in a window causes a crash."
href="https://bugs.webkit.org/show_bug.cgi?id=154444">bug 154444</a>
from <span class="vcard"><a class="email" href="mailto:zan@falconsigh.net" title="Zan Dobersek <zan@falconsigh.net>"> <span class="fn">Zan Dobersek</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=154444#c15">comment #15</a>)
<span class="quote">> > > 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.
> </span >
In case the handle is null you don't need to call the modified ensureGLContext(), it should be enough to just destroy the current GLContext on the spot. And the update should only be issued in case of a non-null handle -- if it's null, renderLayerTree() will bail out early anyway because of an inactive scene.
<span class="quote">> > > 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.</span >
This method is called on the main thread, just like the layer flushes. You shouldn't have to worry about spurious layer flushes occurring while executing this method.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>