cc: Implement deadline scheduling disabled by default

cc: Implement deadline scheduling disabled by default

This patch adds logic to the Scheduler to actually use the BeginFrame
and deadline, but is not enabled by default on any platform yet. This
will ensure emulation of old scheduler in the fallback path is sane.
Emulation of the old path is implemented using an immediate deadline.

SchedulerStateMachine::begin_frame_state has been added and can be in one
of 4 states: Idle, InsideBeginFrame, DeadlinePending, or InsideDeadline.

Notable restrictions of the states are:
- We start a commit as soon after InsideBeginFrame as we can, since the
BeginFrame will be coordinated with user input. (True on Android.
Soon to be true on other platforms.)
- We do not start a commit while Idle, in order to wait for the next
batch of user input.
- Draw and swap only occurs during the InsideDeadline state.

The deadlines of the Browser and Renderer compositors can be nested in
order to have a total draw latency of < 1 frame when starting off. If we
can't hit 1 frame of latency consistently, we will fall back to a higher
latency mode to increase throughput.

TBR=enne@chromium.org
BUG=243461
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=224560

[brianderson, 2013-09-20 22:42:07]

Carrying over enne's lgtm with TBR.

I talked with Tom and Vangelis. If I land this patch now, it will not affect
WinAura experiments they are running tonight.  

Going ahead with the cq.

[commit-bot: I haz the power, 2013-09-20 22:43:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brianderson@chromium.org/24070006/1

[commit-bot: I haz the power, 2013-09-21 04:10:10]

Change committed as 224560

[Sami, 2013-09-25 13:42:51]

https://codereview.chromium.org/24070006/diff/1/cc/scheduler/scheduler.cc
File cc/scheduler/scheduler.cc (right):

https://codereview.chromium.org/24070006/diff/1/cc/scheduler/scheduler.cc#new...
cc/scheduler/scheduler.cc:210: // frame time) properly instead of using this
hack.
Just curious: was the idea to handle this with a proactive BeginFrame or did you
have something else in mind? Reusing the expired BeginFrame like this is still
likely faster, but might cause trouble on the browser compositor side.

[brianderson, 2013-10-02 11:30:14]

https://codereview.chromium.org/24070006/diff/1/cc/scheduler/scheduler.cc
File cc/scheduler/scheduler.cc (right):

https://codereview.chromium.org/24070006/diff/1/cc/scheduler/scheduler.cc#new...
cc/scheduler/scheduler.cc:210: // frame time) properly instead of using this
hack.
On 2013/09/25 13:42:52, Sami wrote:
> Just curious: was the idea to handle this with a proactive BeginFrame or did
you
> have something else in mind? Reusing the expired BeginFrame like this is still
> likely faster, but might cause trouble on the browser compositor side.

Yes, we would enter this case if a proactive BeginFrame was requested because of
a pending commit, but there were no impl-side animations or input handlers.

This case could cause us to draw after the deadline, but there is no reason to
wait for the next BeginFrame since the result of drawing then will be the same. 
The deadline is pretty fuzzy, so we might still make it in time for the browser
compositor to pick it up and make its own deadline.  If not, the browser
compositor needs to handle cases when the renderer misses its deadline anyway,
in which case we should end up in a high-latency mode if we were previously in a
low-latency mode (and the browser compositor couldn't wait before drawing its
next frame), or a skipped frame if we are already in a high-latency mode.