[Webkit-unassigned] [Bug 47848] [chromium] Check getGraphicsResetStatusARB and reinitialize the renderer in an error is returned.

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Vangelis Kokkevis <vangelis at chromium.org>  2010-10-18 16:33:06 PST ---
(From update of attachment 71082)
View in context: https://bugs.webkit.org/attachment.cgi?id=71082&action=review

> WebKit/chromium/src/WebViewImpl.cpp:2484
> +void WebViewImpl::reallocateRenderer(void)

I don't believe that (void) is common in WebKit for methods that take no arguments.

> WebKit/chromium/src/WebViewImpl.cpp:2487
> +    RefPtr<GraphicsContext3D> newContext = GraphicsContext3D::create(context->getContextAttributes(), m_page->chrome(), GraphicsContext3D::RenderDirectlyToHostWindow);

It's not guaranteed that either the newContext or the layerRenderer will be non-null. We need to check against failures.  There's some logic to keep track of failed creation attempts in WebViewImpl::setIsAcceleratedCompositingActive() that we'll need to use here as well.
If the context is lost, what are the chances we'll be able to re-create it right away?  If we fail to create a context should we give up after the first attempt?  We'll need to figure out what happens in a real context lost event on windows.

> WebKit/chromium/src/WebViewImpl.cpp:2494
> +    m_layerRenderer->rootLayer()->setNeedsDisplayRecursive();

I think that instead of calling setNeedsDisplayRecursive, you can modify LayerChromium::setLayerRenderer to call setNeedsDisplay() after calling cleanupResources(). That way, even layers that are currently not connected to layer hierarchy for some reason will be marked dirty before trying to render.

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