[Webkit-unassigned] [Bug 53722] Hook up WebGraphicsContext3D::setContextLostCallback.

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Alexey Marinichev <amarinichev at chromium.org>  2011-02-04 15:39:26 PST ---
> > Source/WebCore/html/canvas/WebGLRenderingContext.cpp:378
> > +    m_context->setContextLostCallback(new WebGLRenderingContextLostCallback(this));
> 
> naked new. Should use adoptPtr(new ...);

Done.

> 
> > Source/WebKit/chromium/src/GraphicsContext3DChromium.cpp:1110
> > +    m_impl->setContextLostCallback(m_contextLostCallbackAdapter.get());
> 
> Is there an ownership issue here? Does the WebGraphicsContext3D take ownership of the passed callback like GraphicsContext3D and WebGLRenderingContext or not?

WebGraphicsContext3DCommandBufferImpl has an OnSwapBuffers call, OnContextLost was added to it in a similar fashion.  Whoever owns WebGraphicsContext3D gets to own the callback.

GraphicsContext3DInternal::m_contextLostCallbackAdapter is an adapter to allow using GraphicsContext3D::ContextLostCallback in WebGraphicsContext3D that does not know about GraphicsContext3D.

WebGLRenderingContext doesn't seem to own GraphicsContext3D -- it has it as RefPtr.  It looks like WebGLRenderingContextLostCallback::m_contextLostCallback should really be a weak pointer -- we don't want to crash if WebGLRenderingContext is already gone and somebody still holds on to GraphicsContext3D.

Need to redo WebGLRenderingContextLostCallback!

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