[Webkit-unassigned] [Bug 47432] No longer ASSERT for LayerRenderer in VideoLayerChromium destructor

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 13 09:48:26 PDT 2010


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





--- Comment #11 from Vangelis Kokkevis <vangelis at chromium.org>  2010-10-13 09:48:26 PST ---
> 
> Besides testing, instead of early return if we have a good way to check if compositor is inactive we can skip creating VideoLayerChromium, any thoughts on this?

As the code stands right now, the VideoLayerChromium gets created after checking for supportsAcceleratedRendering().  However, supportsAcceleratedRendering() uses the value from contentRenderer()->compositor()->hasAcceleratedCompositing() captured when the WebMediaPlayerClientImpl is first created which isn't necessarily accurate.  One possibility would be to not cache that return value and try to get it every time supportsAcceleratedRendering(). Hopefully this will give a more accurate indication on whether the LayerRendererChromium was successfully created. Even that though isn't guaranteed to be accurate, especially if readyStateChanged() gets called before the compositor for the page is set up.

Overall I think the safest and correct solution is the one currently implemented in the patch.

I think the proper way to test this and other similar failures would be to have a mode in DRT that simulates the failure to create a GL context so that we can test that all the fallback paths work properly.

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



More information about the webkit-unassigned mailing list