RESOLVED FIXED 69776
[chromium] Check for lost context at beginning of compositor's execution
https://bugs.webkit.org/show_bug.cgi?id=69776
Summary [chromium] Check for lost context at beginning of compositor's execution
Kenneth Russell
Reported 2011-10-10 12:58:02 PDT
Currently the compositor checks for the loss of OpenGL context at the end of its execution. In order to implement dynamic GPU switching we need to handle the case where the creation of a WebGL context provokes the loss of the compositor's context. This means that the compositor needs to check for lost context at the beginning of its run as well.
Attachments
Patch (9.10 KB, patch)
2011-10-10 14:59 PDT, Kenneth Russell
no flags
Patch (9.41 KB, patch)
2011-10-10 16:55 PDT, Kenneth Russell
no flags
Kenneth Russell
Comment 1 2011-10-10 14:59:48 PDT
James Robinson
Comment 2 2011-10-10 16:10:12 PDT
Comment on attachment 110409 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=110409&action=review Will this test actually fail without the .cpp changes? I think in general it won't - we don't run the layout tests on any bots that will trigger GPU switching (since we're using osmesa) so I don't think this is providing coverage really - although I may be misunderstanding the testcase. Can you use the existing layoutTestController.loseCompositorContext() functionality to emulate this failure mode? > LayoutTests/platform/chromium/compositing/webgl-loses-compositor-context.html:11 > + layoutTestController.overridePreference("WebKitWebGLEnabled", "1"); does this do anything in Chromium?
Kenneth Russell
Comment 3 2011-10-10 16:55:46 PDT
Kenneth Russell
Comment 4 2011-10-10 16:59:27 PDT
(In reply to comment #2) > (From update of attachment 110409 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=110409&action=review > > Will this test actually fail without the .cpp changes? I think in general it won't - we don't run the layout tests on any bots that will trigger GPU switching (since we're using osmesa) so I don't think this is providing coverage really - although I may be misunderstanding the testcase. It asserts when run in Chrome. I was planning to add it as a UI layout test. > Can you use the existing layoutTestController.loseCompositorContext() functionality to emulate this failure mode? I've added this to the test case but unfortunately it doesn't provoke the assertion failure. In order to do so we'll need to force the loss of context at a lower level -- at the GraphicsContext3D level, I think. > > LayoutTests/platform/chromium/compositing/webgl-loses-compositor-context.html:11 > > + layoutTestController.overridePreference("WebKitWebGLEnabled", "1"); > > does this do anything in Chromium? It was necessary in order to get the WebGL context to be created.
Kenneth Russell
Comment 5 2011-10-11 12:14:55 PDT
Ping. This blocks the fix for http://crbug.com/88788 .
James Robinson
Comment 6 2011-10-11 12:27:47 PDT
Comment on attachment 110438 [details] Patch Looks good. If you have time, it'd be great if you could plumb loseCompositorContext() through deeper to make the test more useful.
Kenneth Russell
Comment 7 2011-10-11 16:08:09 PDT
(In reply to comment #6) > (From update of attachment 110438 [details]) > Looks good. If you have time, it'd be great if you could plumb loseCompositorContext() through deeper to make the test more useful. Yes, I'd like to do that. Filed https://bugs.webkit.org/show_bug.cgi?id=69878 to track it.
WebKit Review Bot
Comment 8 2011-10-11 16:33:45 PDT
Comment on attachment 110438 [details] Patch Clearing flags on attachment: 110438 Committed r97194: <http://trac.webkit.org/changeset/97194>
WebKit Review Bot
Comment 9 2011-10-11 16:33:49 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.