Bug 66820 - [chromium] Need a way to test lost compositor context recovery
Summary: [chromium] Need a way to test lost compositor context recovery
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Robinson
URL:
Keywords:
Depends on: 66814
Blocks:
  Show dependency tree / graph
 
Reported: 2011-08-23 16:30 PDT by James Robinson
Modified: 2011-08-23 18:33 PDT (History)
5 users (show)

See Also:

Attachments
Patch (10.26 KB, patch)
2011-08-23 16:36 PDT, James Robinson 		no flags Details | Formatted Diff | Diff
merged up and including expectations (11.23 KB, patch)
2011-08-23 17:26 PDT, James Robinson 		kbr: review+
Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Robinson 2011-08-23 16:30:27 PDT 
[chromium] Need a way to test lost compositor context recovery
Comment 1 James Robinson 2011-08-23 16:36:09 PDT 
Created attachment 104929 [details]
Patch
Comment 2 James Robinson 2011-08-23 16:37:11 PDT 
Note that this test currently crashes because of https://bugs.webkit.org/show_bug.cgi?id=66814. This has been broken for a while now, but since we don't have a layout test for it it just keeps failing.
Comment 3 Adrienne Walker 2011-08-23 17:00:42 PDT 
Comment on attachment 104929 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=104929&action=review

This is super exciting.

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.cpp:128
> -    doComposite();
> +    composite(false);

If this is to fix the WebGL path, can you add a lose compositor context test that involves WebGL?
Comment 4 James Robinson 2011-08-23 17:03:39 PDT 
It's not for the WebGL path, it's for DumpRenderTree which uses the compositeAndReadback() path in order to get access to the composited content.  It never calls WebWidget::composite().

I think that we should write some patches to make sure that things like WebGL and canvas keep working after a lost compositor context, this is just the start.
Comment 5 Adrienne Walker 2011-08-23 17:08:00 PDT 
(In reply to comment #4)
> It's not for the WebGL path, it's for DumpRenderTree which uses the compositeAndReadback() path in order to get access to the composited content.  It never calls WebWidget::composite().
> 
> I think that we should write some patches to make sure that things like WebGL and canvas keep working after a lost compositor context, this is just the start.

Ah, then I misunderstood how that was being used.  I wish DRT wasn't such a special case.

In that case, unofficial LGTM once this test starts passing.  

...and, more tests in the future would be more awesome.
Comment 6 James Robinson 2011-08-23 17:26:04 PDT 
Created attachment 104943 [details]
merged up and including expectations
Comment 7 Kenneth Russell 2011-08-23 17:41:33 PDT 
Comment on attachment 104943 [details]
merged up and including expectations

This is great. Big thumbs up. Do you want to submit this to the EWS before r+?
Comment 8 James Robinson 2011-08-23 17:43:09 PDT 
Yes, I'll submit to EWS and mark review? once it's safe to land.  Right now this test actually crashes because we have bugs in our context recovery, so it can't land yet - I'm waiting for https://bugs.webkit.org/show_bug.cgi?id=66814 which is r+ cq+.
Comment 9 Kenneth Russell 2011-08-23 18:24:33 PDT 
Comment on attachment 104943 [details]
merged up and including expectations

r=me
Comment 10 James Robinson 2011-08-23 18:33:25 PDT 
Committed r93681: <http://trac.webkit.org/changeset/93681>