Reland of cc: Remove frame queuing from the scheduler.

Reland of cc: Remove frame queuing from the scheduler.

Original issue's description:
> cc: Remove frame queuing from the scheduler.
>
> CC scheduler has a frame queuing mechanism called "retro frames". This
> has been responsible for a lot of complexity and hard to fix bugs. The
> original intent for adding retro frames was to allow the scheduler to
> handle multiple frames in flight but that goal doesn't seem feasible or
> even desirable any more. This CL removes the retro frames queue and
> instead makes the Scheduler end the previous frame when it receives a
> BeginFrame message.
>
> One surprising behavior was that SyntheticBFS MISSED frames would be
> queued as retro frames and this would convert the synchronous begin
> frame call (inside Scheduler::ProcessScheduledActions) to an
> asynchronous retro frame PostTask. To work around this the Scheduler
> keeps track of a single CancelableClosure that's used for MISSED frames.
>
> The above behavior was also causing the BeginFramesNotFromClient tests
> to work even though there was an extra MISSED frame in the queue. This
> is more elegantly solved in another way by using frame number to advance
> the task runner instead of just running pending tasks.
>
> Lastly SchedulerStateMachine is modified so that it's possible to end
> the previous frame and still have the same behavior as before in the
> commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,danakj@chromium.org,enne@chromium.org
BUG=602485, 644992, 651387
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/da928f0adc826e2e5e32ba08da7019eb9a0ed912
Cr-Commit-Position: refs/heads/master@{#424027}

[sunnyps, 2016-10-05 01:27:53]

Description was changed from

==========
Reland of cc: Remove frame queuing from the scheduler.

Original issue's description:
> cc: Remove frame queuing from the scheduler.
>
> CC scheduler has a frame queuing mechanism called "retro frames". This
> has been responsible for a lot of complexity and hard to fix bugs. The
> original intent for adding retro frames was to allow the scheduler to
> handle multiple frames in flight but that goal doesn't seem feasible or
> even desirable any more. This CL removes the retro frames queue and
> instead makes the Scheduler end the previous frame when it receives a
> BeginFrame message.
>
> One surprising behavior was that SyntheticBFS MISSED frames would be
> queued as retro frames and this would convert the synchronous begin
> frame call (inside Scheduler::ProcessScheduledActions) to an
> asynchronous retro frame PostTask. To work around this the Scheduler
> keeps track of a single CancelableClosure that's used for MISSED frames.
>
> The above behavior was also causing the BeginFramesNotFromClient tests
> to work even though there was an extra MISSED frame in the queue. This
> is more elegantly solved in another way by using frame number to advance
> the task runner instead of just running pending tasks.
>
> Lastly SchedulerStateMachine is modified so that it's possible to end
> the previous frame and still have the same behavior as before in the
> commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,danakj@chromium.org,enne@chromium.org
BUG=602485, 644992, 651387
==========

to

==========
Reland of cc: Remove frame queuing from the scheduler.

Original issue's description:
> cc: Remove frame queuing from the scheduler.
>
> CC scheduler has a frame queuing mechanism called "retro frames". This
> has been responsible for a lot of complexity and hard to fix bugs. The
> original intent for adding retro frames was to allow the scheduler to
> handle multiple frames in flight but that goal doesn't seem feasible or
> even desirable any more. This CL removes the retro frames queue and
> instead makes the Scheduler end the previous frame when it receives a
> BeginFrame message.
>
> One surprising behavior was that SyntheticBFS MISSED frames would be
> queued as retro frames and this would convert the synchronous begin
> frame call (inside Scheduler::ProcessScheduledActions) to an
> asynchronous retro frame PostTask. To work around this the Scheduler
> keeps track of a single CancelableClosure that's used for MISSED frames.
>
> The above behavior was also causing the BeginFramesNotFromClient tests
> to work even though there was an extra MISSED frame in the queue. This
> is more elegantly solved in another way by using frame number to advance
> the task runner instead of just running pending tasks.
>
> Lastly SchedulerStateMachine is modified so that it's possible to end
> the previous frame and still have the same behavior as before in the
> commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,danakj@chromium.org,enne@chromium.org
BUG=602485, 644992, 651387
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[sunnyps, 2016-10-07 03:04:42]

The CQ bit was checked by sunnyps@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 03:04:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 03:07:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-07 03:07:27]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[sunnyps, 2016-10-07 03:10:04]

Trying to reland this again. This fixes the crash in crbug.com/651387
(activation being performed inside ProxyImpl dtor). The fix for the context_loss
test flakes is in https://codereview.chromium.org/2387333003/.

The only change from last patch is the addition of Scheduler::Stop and the
associated test. I tried preventing activation only by calling DidLoseCFS but
that's very hard to test and doesn't make shutdown safe from similar issues that
may arise.

PTAL - the first two patch sets are a plain reland + rebase so please only look
at the others.

[sunnyps, 2016-10-07 03:13:04]

The CQ bit was checked by sunnyps@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 03:13:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 04:33:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-07 04:33:50]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[enne (OOO), 2016-10-07 18:41:31]

I do agree that we're at the point where the "stop everything" state is the only
way to solve this definitively.  This lgtm.  Thanks for wrangling this bug.  :)

[sunnyps, 2016-10-07 23:56:25]

The CQ bit was checked by sunnyps@chromium.org

[commit-bot: I haz the power, 2016-10-07 23:56:42]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-08 00:33:41]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-10-08 00:37:31]

Description was changed from

==========
Reland of cc: Remove frame queuing from the scheduler.

Original issue's description:
> cc: Remove frame queuing from the scheduler.
>
> CC scheduler has a frame queuing mechanism called "retro frames". This
> has been responsible for a lot of complexity and hard to fix bugs. The
> original intent for adding retro frames was to allow the scheduler to
> handle multiple frames in flight but that goal doesn't seem feasible or
> even desirable any more. This CL removes the retro frames queue and
> instead makes the Scheduler end the previous frame when it receives a
> BeginFrame message.
>
> One surprising behavior was that SyntheticBFS MISSED frames would be
> queued as retro frames and this would convert the synchronous begin
> frame call (inside Scheduler::ProcessScheduledActions) to an
> asynchronous retro frame PostTask. To work around this the Scheduler
> keeps track of a single CancelableClosure that's used for MISSED frames.
>
> The above behavior was also causing the BeginFramesNotFromClient tests
> to work even though there was an extra MISSED frame in the queue. This
> is more elegantly solved in another way by using frame number to advance
> the task runner instead of just running pending tasks.
>
> Lastly SchedulerStateMachine is modified so that it's possible to end
> the previous frame and still have the same behavior as before in the
> commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,danakj@chromium.org,enne@chromium.org
BUG=602485, 644992, 651387
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
Reland of cc: Remove frame queuing from the scheduler.

Original issue's description:
> cc: Remove frame queuing from the scheduler.
>
> CC scheduler has a frame queuing mechanism called "retro frames". This
> has been responsible for a lot of complexity and hard to fix bugs. The
> original intent for adding retro frames was to allow the scheduler to
> handle multiple frames in flight but that goal doesn't seem feasible or
> even desirable any more. This CL removes the retro frames queue and
> instead makes the Scheduler end the previous frame when it receives a
> BeginFrame message.
>
> One surprising behavior was that SyntheticBFS MISSED frames would be
> queued as retro frames and this would convert the synchronous begin
> frame call (inside Scheduler::ProcessScheduledActions) to an
> asynchronous retro frame PostTask. To work around this the Scheduler
> keeps track of a single CancelableClosure that's used for MISSED frames.
>
> The above behavior was also causing the BeginFramesNotFromClient tests
> to work even though there was an extra MISSED frame in the queue. This
> is more elegantly solved in another way by using frame number to advance
> the task runner instead of just running pending tasks.
>
> Lastly SchedulerStateMachine is modified so that it's possible to end
> the previous frame and still have the same behavior as before in the
> commit to active tree (browser compositor) mode.

R=brianderson@chromium.org,danakj@chromium.org,enne@chromium.org
BUG=602485, 644992, 651387
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/da928f0adc826e2e5e32ba08da7019eb9a0ed912
Cr-Commit-Position: refs/heads/master@{#424027}
==========

[commit-bot: I haz the power, 2016-10-08 00:37:32]

Patchset 5 (id:??) landed as
https://crrev.com/da928f0adc826e2e5e32ba08da7019eb9a0ed912
Cr-Commit-Position: refs/heads/master@{#424027}