cc: Remove retro frames from scheduler.

cc: Remove retro frames from scheduler.

The scheduler would enqueue any begin frame received while it was
handling a previous begin frame as a "retro" frame. After the previous
begin frame was finished the scheduler would post a task to dequeue a
retro frame and then handle it if there was still time. This caused a
lot of hard to debug issues.

This CL removes the queue of retro frames from the scheduler. Instead
the scheduler just drops any incoming begin frame received when it's not
ready to handle it. After finishing the previous begin frame the
scheduler tells the begin frame source that it's ready to handle a new
frame and the frame source might choose to send a begin frame that was
rejected by the scheduler as a "MISSED" begin frame.

This CL also removes the "BEGIN_FRAME_STARTING" state from the scheduler
because it was only needed when animations were driven by the scheduler.

BUG=602485
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

[sunnyps, 2016-04-14 22:09:22]

Description was changed from

==========
cc: Remove retro frames from scheduler.

The scheduler would enqueue any begin frame received while it was
handling a previous begin frame as a "retro" frame. After the previous
begin frame was finished the scheduler would post a task to dequeue a
retro frame and then handle it if there was still time. This caused a
lot of hard to debug issues.

This CL removes the queue of retro frames from the scheduler. Instead
the scheduler just drops any incoming begin frame received when it's not
ready to handle it. After finishing the previous begin frame the
scheduler tells the begin frame source that it's ready to handle a new
frame and the frame source might choose to send a begin frame that was
rejected by the scheduler as a "MISSED" begin frame.

This CL also removes the "BEGIN_FRAME_STARTING" state from the scheduler
because it was only needed when animations were driven by the scheduler.

BUG=602485
==========

to

==========
cc: Remove retro frames from scheduler.

The scheduler would enqueue any begin frame received while it was
handling a previous begin frame as a "retro" frame. After the previous
begin frame was finished the scheduler would post a task to dequeue a
retro frame and then handle it if there was still time. This caused a
lot of hard to debug issues.

This CL removes the queue of retro frames from the scheduler. Instead
the scheduler just drops any incoming begin frame received when it's not
ready to handle it. After finishing the previous begin frame the
scheduler tells the begin frame source that it's ready to handle a new
frame and the frame source might choose to send a begin frame that was
rejected by the scheduler as a "MISSED" begin frame.

This CL also removes the "BEGIN_FRAME_STARTING" state from the scheduler
because it was only needed when animations were driven by the scheduler.

BUG=602485
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[sunnyps, 2016-04-14 22:21:21]

sunnyps@chromium.org changed reviewers:
+ enne@chromium.org, sievers@chromium.org

[sunnyps, 2016-04-14 22:21:21]

PTAL

The scheduler behaves more sanely with this change. The only task that's posted
by the scheduler is the deadline. Everything else behaves synchronously.

The code for handling DidFinishFrame is duplicated in the various BFS classes.
I'm looking for a way to fix that.

sievers@, can you try your CompositorImplAndroid changes with  this CL and see
if it fixes the omnibar hiding problem?

[enne (OOO), 2016-04-14 23:02:26]

This is excellent cleanup.  :)

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/begin_frame_so...
File cc/scheduler/begin_frame_source.cc (right):

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/begin_frame_so...
cc/scheduler/begin_frame_source.cc:147: PostBeginFrame();
Hmm.  Should this only post a begin frame to the observer that finished?
Otherwise, if you have two observers, when one finishes, you'll post two new
begin frames?

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/begin_frame_so...
File cc/scheduler/begin_frame_source.h (left):

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/begin_frame_so...
cc/scheduler/begin_frame_source.h:78: class CC_EXPORT BeginFrameObserverBase :
public BeginFrameObserver {
Hmm, this was useful because it implemented some functions like
LastUsedBeginFrameArgs and AsValueInto automatically.  I was going to use these
in https://codereview.chromium.org/1841083007/.  Maybe it should just be wrapped
into the base class or there's some other cleanup that makes sense.  What do you
think?

https://codereview.chromium.org/1887243002/diff/1/content/renderer/gpu/compos...
File content/renderer/gpu/compositor_external_begin_frame_source.cc (right):

https://codereview.chromium.org/1887243002/diff/1/content/renderer/gpu/compos...
content/renderer/gpu/compositor_external_begin_frame_source.cc:46:
SetClientReady();
Why do you need to call this? This should have already happened as soon as there
was an observer, I think?

https://codereview.chromium.org/1887243002/diff/1/content/renderer/gpu/compos...
content/renderer/gpu/compositor_external_begin_frame_source.cc:47: // Send a
MISSED begin frame if necessary.
This looks like a pretty common pattern.  Is there some clean way to not repeat
this?

[enne (OOO), 2016-04-18 21:30:38]

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/scheduler.cc
File cc/scheduler/scheduler.cc (left):

https://codereview.chromium.org/1887243002/diff/1/cc/scheduler/scheduler.cc#o...
cc/scheduler/scheduler.cc:307: if (adjusted_args.type == BeginFrameArgs::MISSED)
{
The removal of this might break https://codereview.chromium.org/1879833002/.

[sunnyps, 2017-03-01 23:43:56]

Description was changed from

==========
cc: Remove retro frames from scheduler.

The scheduler would enqueue any begin frame received while it was
handling a previous begin frame as a "retro" frame. After the previous
begin frame was finished the scheduler would post a task to dequeue a
retro frame and then handle it if there was still time. This caused a
lot of hard to debug issues.

This CL removes the queue of retro frames from the scheduler. Instead
the scheduler just drops any incoming begin frame received when it's not
ready to handle it. After finishing the previous begin frame the
scheduler tells the begin frame source that it's ready to handle a new
frame and the frame source might choose to send a begin frame that was
rejected by the scheduler as a "MISSED" begin frame.

This CL also removes the "BEGIN_FRAME_STARTING" state from the scheduler
because it was only needed when animations were driven by the scheduler.

BUG=602485
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc: Remove retro frames from scheduler.

The scheduler would enqueue any begin frame received while it was
handling a previous begin frame as a "retro" frame. After the previous
begin frame was finished the scheduler would post a task to dequeue a
retro frame and then handle it if there was still time. This caused a
lot of hard to debug issues.

This CL removes the queue of retro frames from the scheduler. Instead
the scheduler just drops any incoming begin frame received when it's not
ready to handle it. After finishing the previous begin frame the
scheduler tells the begin frame source that it's ready to handle a new
frame and the frame source might choose to send a begin frame that was
rejected by the scheduler as a "MISSED" begin frame.

This CL also removes the "BEGIN_FRAME_STARTING" state from the scheduler
because it was only needed when animations were driven by the scheduler.

BUG=602485
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========