[Webkit-unassigned] [Bug 129419] [GTK] Wrong GL context when destroying textures

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Iago Toral <itoral at igalia.com>  2014-03-05 05:16:34 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > Okay. I think your original approach is the way to go, but I hope we can find a way to do it without adding another class. :/
> 
> Unfortunately my patch seems to work well always when going through EGL but when going with the GLX path it seems that some times it does not work, so this solution is not 100% reliable in all cases.
> 
> I guess this still needs more investigation.

Found the reason:

The problem is that the tear down sequence in WebPage::close goes so that WebCore::FrameLoader::detachFromParent() is called first (this will produce destruction of GL objects via GraphicsContext3D) and then the drawing area is destroyed (which invalidates the layer tree host).

I was working under the assumption that this tear down sequence is always like that and hence making sure that only the destruction of the layer tree host's context would destroy the actual GL context (that is, the pixmaps, surfaces, etc) but in some unusual circumstances it looks like LayerTreeHostGtk::invalidate can be called before WebPage::close. This happens due to a timer like this:

#1  0x00007fb9e4fdb9a3 in WebKit::DrawingAreaImpl::exitAcceleratedCompositingMode() () from /home/itoral/Devel/Gnome/bin/lib64/libwebkit2gtk-3.0.so.25
#2  0x00007fb9e431f5e2 in WTF::RunLoop::TimerBase::timerFiredCallback(WTF::RunLoop::TimerBase*) () from /home/itoral/Devel/Gnome/bin/lib64/libjavascriptcoregtk-3.0.so.0
#3  0x00007fb9e0f5e206 in g_timeout_dispatch (source=0x37d0310, callback=0x7fb9e431f5c0 <WTF::RunLoop::TimerBase::timerFiredCallback(WTF::RunLoop::TimerBase*)>, 
    user_data=0x3502d30) at gmain.c:4450
#4  0x00007fb9e0f5c4e0 in g_main_dispatch (context=0xf50ac0) at gmain.c:3066
#5  0x00007fb9e0f5d20e in g_main_context_dispatch (context=0xf50ac0) at gmain.c:3641

This creates a problem because we can only allow the underlying GL context to be really destroyed when we know for sure that both the layer tree host and the GraphicsContext3D are done with it which, according to this, can happen in any order.

I think the way to fix this would be to make the GLContext instance used by both the layer tree host and the GraphicsContext3D a RefPtr instead of an OwnPtr. I think this would allow us to just use the same GLContext instance for both and make sure it won't be destroyed until both objects are done with it. This would require to change the signature of the GLContext::create*() functions.

Martin, what do you think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.