Bug 72041 - [chromium] Pipe compositor begin/end frame up to WebWidgetClient
Summary: [chromium] Pipe compositor begin/end frame up to WebWidgetClient
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: Adrienne Walker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-10 12:20 PST by Adrienne Walker
Modified: 2011-11-14 15:10 PST (History)
9 users (show)

See Also:


Attachments
Patch (10.43 KB, patch)
2011-11-10 12:28 PST, Adrienne Walker
no flags Details | Formatted Diff | Diff
Rebaselined (10.50 KB, patch)
2011-11-10 12:43 PST, Adrienne Walker
no flags Details | Formatted Diff | Diff
Rename functions, pipe swapbuffers properly (10.86 KB, patch)
2011-11-11 14:08 PST, Adrienne Walker
no flags Details | Formatted Diff | Diff
Now with compiling tests (11.72 KB, patch)
2011-11-12 12:02 PST, Adrienne Walker
no flags Details | Formatted Diff | Diff
Address nits (11.87 KB, patch)
2011-11-14 12:09 PST, Adrienne Walker
fishd: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrienne Walker 2011-11-10 12:20:50 PST
[chromium] Pipe compositor begin/end frame up to WebWidgetClient
Comment 1 Adrienne Walker 2011-11-10 12:28:25 PST
Created attachment 114541 [details]
Patch
Comment 2 Adrienne Walker 2011-11-10 12:28:59 PST
This corresponds to a Chromium change here: http://codereview.chromium.org/8528006
Comment 3 WebKit Review Bot 2011-11-10 12:30:30 PST
Please wait for approval from fishd@chromium.org before submitting because this patch contains changes to the Chromium public API.
Comment 4 James Robinson 2011-11-10 12:32:58 PST
There seem to be merge conflicts here
Comment 5 Adrienne Walker 2011-11-10 12:43:36 PST
Created attachment 114546 [details]
Rebaselined
Comment 6 James Robinson 2011-11-10 13:30:56 PST
Comment on attachment 114546 [details]
Rebaselined

Looks good, need Darin to approve the WebWidgetClient changes
Comment 7 Darin Fisher (:fishd, Google) 2011-11-10 20:08:51 PST
Comment on attachment 114546 [details]
Rebaselined

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

> Source/WebKit/chromium/public/WebWidgetClient.h:63
> +    virtual void didBeginFrame() { }

the term "Frame" is a bit overloaded.  see WebFrame.  WebView extends from WebWidget.  WebView has a tree of frames.  See how this can get confusing?  Maybe we can try to stick to using terms involving variations of the word "compositor"?
Comment 8 Nat Duca 2011-11-10 21:21:39 PST
Comment on attachment 114546 [details]
Rebaselined

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

(In reply to comment #7)
> the term "Frame" is a bit overloaded.  see WebFrame.  WebView extends from WebWidget.  WebView has a tree of frames.  See how this can get confusing?  Maybe we can try to stick to using terms involving variations of the word "compositor"?

Can we do CompositorFrame? We're gonna kill ourselves if we try to not use the word frame, since that's the word we use in graphics... long term, maybe what we should do is remove all this stuff from the WebWidget API and instead have WebWidget have a WebLayerTreeView* accessor that gives access to WebViewImpl::m_layerTreeHost. That'd avoid this better...

> Source/WebCore/platform/graphics/chromium/cc/CCLayerTreeHost.h:61
> +    virtual void didFinishFrame() = 0;

Struggling with the renaming to didFinishFrame here (sorry to be 'that guy'!). We have a finishAllRendering and this definitely isn't related to that. Also it should be clear what was done --- its not that the GPU has finished the work [e.g. swap-ack driven], just that its been submitted. That's why it was so pedantically named as it was before.

> Source/WebCore/platform/graphics/chromium/cc/CCSingleThreadProxy.cpp:307
> +        m_layerTreeHost->didFinishFrame();

Ooh, does this mean that we can stop the WebGraphicsContext from calling didSwap/etc on the RenderView? That's causing me some headaches right now..

> Source/WebKit/chromium/src/WebViewImpl.cpp:2783
> +    m_client->didFinishFrame();

Do we need a null-check? I forget...
Comment 9 Adrienne Walker 2011-11-11 14:08:58 PST
Created attachment 114769 [details]
Rename functions, pipe swapbuffers properly
Comment 10 Nat Duca 2011-11-11 14:13:16 PST
Comment on attachment 114769 [details]
Rename functions, pipe swapbuffers properly

Awesome. Jamesr or darin for official ceremony.
Comment 11 James Robinson 2011-11-11 14:37:50 PST
Comment on attachment 114769 [details]
Rename functions, pipe swapbuffers properly

R=me on everything but WebWidgetClient.h, please wait for Darin on that.
Comment 12 WebKit Review Bot 2011-11-11 22:42:11 PST
Comment on attachment 114769 [details]
Rename functions, pipe swapbuffers properly

Attachment 114769 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10460592
Comment 13 Adrienne Walker 2011-11-12 12:02:03 PST
Created attachment 114840 [details]
Now with compiling tests
Comment 14 Darin Fisher (:fishd, Google) 2011-11-14 10:18:46 PST
Comment on attachment 114840 [details]
Now with compiling tests

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

> Source/WebKit/chromium/public/WebWidgetClient.h:63
> +    virtual void didCommitAndDrawCompositorFrame() { }

nit: please add some documentation explaining what these events are telling the embedder.

> Source/WebKit/chromium/public/WebWidgetClient.h:64
> +    virtual void didCompleteSwapbuffers() { }

nit: should it be SwapBuffers... with a capital B?
Comment 15 Adrienne Walker 2011-11-14 12:09:29 PST
Created attachment 114999 [details]
Address nits
Comment 16 Darin Fisher (:fishd, Google) 2011-11-14 14:46:21 PST
Comment on attachment 114999 [details]
Address nits

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

> Source/WebKit/chromium/public/WebWidgetClient.h:66
> +    // Called for compositing mode when swapbuffers has been posted in the GPU

nit: insert new line above the start of a comment block.
Comment 17 James Robinson 2011-11-14 14:48:37 PST
Comment on attachment 114999 [details]
Address nits

R=me
Comment 18 Adrienne Walker 2011-11-14 15:10:28 PST
Committed r100199: <http://trac.webkit.org/changeset/100199>