Add DisplayScheduler to enable BeginFrame-based scheduling of surfaces.

Add DisplayScheduler to enable BeginFrame-based scheduling of surfaces.

This implementation always uses a SyntheticBeginFrameSource to schedule the final Display draw.

[jbauman, 2014-11-13 23:48:20]

jbauman@chromium.org changed reviewers:
+ brianderson@chromium.org

[jbauman, 2014-11-13 23:48:20]

This is basically how I'd want to switch Surfaces over to using BeginFrame. I'm
not certain that I'm using it correctly, though; eg, should it be turning
SetNeedsBeginFrames on and off every single frame?

[brianderson, 2014-11-15 00:02:19]

On 2014/11/13 23:48:20, jbauman wrote:
> This is basically how I'd want to switch Surfaces over to using BeginFrame.
I'm
> not certain that I'm using it correctly, though; eg, should it be turning
> SetNeedsBeginFrames on and off every single frame?

The cc::Scheduler keeps SetNeedsBeginFrames true for an extra frame before
really going idle. This avoids unnecessary message latency/overhead. Although
this scheduler doesn't need to worry about messages, it might help for when we
are hooking into the platform's callbacks on Android and Mac. For now though,
the SyntheticBeginFrameSource should support a glitchy SetNeedsBeginFrames
without much overhead or spurious BeginFrames.

[jbauman, 2014-11-18 00:08:40]

jbauman@chromium.org changed reviewers:
+ jamesr@chromium.org

[brianderson, 2014-11-19 02:40:21]

brianderson@chromium.org changed reviewers:
+ sunnyps@chromium.org

[brianderson, 2014-11-19 02:40:21]

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
File cc/surfaces/display_scheduler.cc (right):

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
cc/surfaces/display_scheduler.cc:71: void DisplayScheduler::OnBeginFrame(const
BeginFrameArgs& args) {
Until the DisplayScheduler has knowledge about all children that are trying to
swap, it is probably better if we don't use a deadline. Once DisplayScheduler
knows about all children, it can trigger the deadline early once all children
have swapped.

For now, I think it'll work nice if you just call Draw() synchronously from
OnBeginFrame.

[mithro-old, 2015-02-27 02:27:43]

mithro@mithis.com changed reviewers:
+ mithro@mithis.com

[mithro-old, 2015-03-11 04:19:25]

Hi jbauman,

I'm very happy to chat about how I think any new scheduler we write should be
structured. Feel free to drop something into my calendar.

Tim 'mithro' Ansell

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
File cc/surfaces/display_scheduler.h (right):

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
cc/surfaces/display_scheduler.h:17: 
If we writing a new scheduler, I think we should take some time to design a
proper scheduler rather than the mess of a dependency manager masquerading as a
scheduler at the moment. This class seems to be quickly going down the same
route as the current scheduler.

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
cc/surfaces/display_scheduler.h:18: class CC_SURFACES_EXPORT DisplayScheduler :
public BeginFrameObserver {
You should probably inherit from BeginFrameObserverMixIn instead, then you can
remove a bunch of the stuff below.

https://codereview.chromium.org/720333005/diff/40001/cc/surfaces/display_sche...
cc/surfaces/display_scheduler.h:42: scoped_ptr<SyntheticBeginFrameSource>
begin_frame_source_;
Why are we hard coding this to a SyntheticBFS rather than just using a generic
BFS?

[brianderson, 2015-03-14 02:22:24]

Talked with John and I'm going to pick this up.

The DisplayScheduler will tie in nicely with the BeginFrame messages Simon is
landing and will ultimately enable Renderer latency recovery.

Sunny: It would be nice to rely on the version pf SyntheticBeginFrameSource that
gets rid of retro frames so we don't need to add retro frames here either.

[mithro-old, 2015-03-23 01:24:53]

jbauman, as brianderson is taking this over can you close this issue?

Thanks!