Bug 92323 - Plumb vsync-enabled flag up to compositor thread and support disable-vsync
Summary: Plumb vsync-enabled flag up to compositor thread and support disable-vsync
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: John Bates
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-25 17:18 PDT by John Bates
Modified: 2012-07-30 15:04 PDT (History)
9 users (show)

See Also:


Attachments
Patch (13.47 KB, patch)
2012-07-25 17:21 PDT, John Bates
no flags Details | Formatted Diff | Diff
Patch (16.24 KB, patch)
2012-07-26 15:26 PDT, John Bates
no flags Details | Formatted Diff | Diff
Patch (17.11 KB, patch)
2012-07-27 15:32 PDT, John Bates
jbates: review-
Details | Formatted Diff | Diff
Patch (18.87 KB, patch)
2012-07-27 17:18 PDT, John Bates
no flags Details | Formatted Diff | Diff
Patch (18.88 KB, patch)
2012-07-30 10:47 PDT, John Bates
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Bates 2012-07-25 17:18:53 PDT
Plumb vsync-enabled flag up to compositor thread and support disable-vsync
Comment 1 John Bates 2012-07-25 17:21:26 PDT
Created attachment 154500 [details]
Patch
Comment 2 WebKit Review Bot 2012-07-25 17:24:16 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment 3 Antoine Labour 2012-07-25 17:42:29 PDT
Comment on attachment 154500 [details]
Patch

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

> Source/Platform/chromium/public/WebLayerTreeViewClient.h:91
> +    virtual bool isRenderingVSynced() const { return true; }

Since this is only queried at startup, wouldn't it be easier to expose on WebLayerTreeView::Settings / CCLayerTreeSettings instead? As is it looks like the client could change it dynamically (but it can't).
Comment 4 John Bates 2012-07-25 17:48:32 PDT
(In reply to comment #3)
> (From update of attachment 154500 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=154500&action=review
> 
> > Source/Platform/chromium/public/WebLayerTreeViewClient.h:91
> > +    virtual bool isRenderingVSynced() const { return true; }
> 
> Since this is only queried at startup, wouldn't it be easier to expose on WebLayerTreeView::Settings / CCLayerTreeSettings instead? As is it looks like the client could change it dynamically (but it can't).

Yeah, I'll try that instead.
Comment 5 Nat Duca 2012-07-25 21:09:52 PDT
Lets see what the settings path looks like.
Comment 6 John Bates 2012-07-26 15:26:32 PDT
Created attachment 154767 [details]
Patch
Comment 7 Antoine Labour 2012-07-26 15:45:55 PDT
LGTM
Comment 8 James Robinson 2012-07-26 15:55:52 PDT
Comment on attachment 154767 [details]
Patch

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

> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.h:57
> +    // Disable framerate throttling by TimeSource, and instead render frames as
> +    // fast as possible.
> +    void disableTimeSourceThrottling(CCThread*);

This feels a bit off - what about having CCThreadProxy simply create a different CCTimeSource and passing that in to the framerate controller?  It could either make a delay based time source with an interval of 0 or another simpler implementation that just did postTask
Comment 9 John Bates 2012-07-26 16:10:13 PDT
Comment on attachment 154767 [details]
Patch

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

>> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.h:57
>> +    void disableTimeSourceThrottling(CCThread*);
> 
> This feels a bit off - what about having CCThreadProxy simply create a different CCTimeSource and passing that in to the framerate controller?  It could either make a delay based time source with an interval of 0 or another simpler implementation that just did postTask

Using CCTimeSource would require some slightly ugly changes elsewhere:
- CCFrameRateController still needs about the same code minus m_manualTicker.
- CCTimeSourceInfinite would have the m_manualTicker code.
- CCTimeSource would need a new virtual like "pollForManualTick" or "forceTick", etc.

Not sure if the vsync-disabled path should add that much complexity. Another option is to virtualize CCFrameRateController and have a vsync-disabled version... That would have the complexity of sharing the m_numFramesPending logic while virtualizing didBeginFrame and didFinishFrame, but might be worth it. Wdyt?
Comment 10 John Bates 2012-07-27 15:32:48 PDT
Created attachment 155068 [details]
Patch
Comment 11 James Robinson 2012-07-27 16:08:10 PDT
Comment on attachment 155068 [details]
Patch

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

Could you update CCFrameRateControllerTest.cpp with at least some basic tests of this class?

> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.cpp:69
> +    // TimeSource ticks are not used in this mode, but we still use it to track
> +    // active state, so make one that ticks slowly.

I don't know what this means - it looks like we post a task whenever the "active" state changes, so I can't figure out why we need another timer.  Is this just because the m_timeSource stores the "active" bool?  We could keep that as a member on CCFrameRateController if we want
Comment 12 James Robinson 2012-07-27 16:08:46 PDT
Comment on attachment 155068 [details]
Patch

I think we need at least a bit of test coverage for the new CCFrameRateController path before landing.
Comment 13 John Bates 2012-07-27 17:18:45 PDT
Created attachment 155093 [details]
Patch
Comment 14 John Bates 2012-07-27 17:20:17 PDT
Comment on attachment 155068 [details]
Patch

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

Added a test for unthrottled behavior.

>> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.cpp:69
>> +    // active state, so make one that ticks slowly.
> 
> I don't know what this means - it looks like we post a task whenever the "active" state changes, so I can't figure out why we need another timer.  Is this just because the m_timeSource stores the "active" bool?  We could keep that as a member on CCFrameRateController if we want

Done.
Comment 15 James Robinson 2012-07-30 10:27:06 PDT
Comment on attachment 155093 [details]
Patch

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

R=me, just one question for you before setting cq?

> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.cpp:91
> +        postManualTick();

do we need to post a tick if we aren't active?
Comment 16 Nat Duca 2012-07-30 10:29:15 PDT
Comment on attachment 155093 [details]
Patch

Nice job!
Comment 17 John Bates 2012-07-30 10:44:55 PDT
Comment on attachment 155093 [details]
Patch

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

>> Source/WebCore/platform/graphics/chromium/cc/CCFrameRateController.cpp:91
>> +        postManualTick();
> 
> do we need to post a tick if we aren't active?

no, but postManualTick early-outs if we aren't active so call-sites don't need the check. otoh, this would probably look clearer if it checked before calling. I'll post a new CL.
Comment 18 John Bates 2012-07-30 10:47:57 PDT
Created attachment 155321 [details]
Patch
Comment 19 WebKit Review Bot 2012-07-30 15:04:17 PDT
Comment on attachment 155321 [details]
Patch

Clearing flags on attachment: 155321

Committed r124097: <http://trac.webkit.org/changeset/124097>
Comment 20 WebKit Review Bot 2012-07-30 15:04:22 PDT
All reviewed patches have been landed.  Closing bug.