cc: Add queue of BeginFrames to support long deadlines.

cc: Add queue of BeginFrames to support long deadlines.

For discussion, not review yet.

This allows us to target a latency of 2 frames or more frames by
allowing the deadline be more than an interval away (i.e. after the
next frame's frame_time.)

A queue of BeginFrames is stored that we can catch up on if we can.

BUG=305264

[Sami, 2013-08-13 16:44:08]

Hooray for better pipelining :) Did you have some specific case where this helps
or is this more speculative?

I think one potential problem here is that the browser no longer knows which
outgoing BeginFrame corresponds to which incoming frame from the renderer
(unless I missed something). Say the renderer has two BeginFrames like this:

      0   1   2   3  vsync
      +---+---+---+-->
      :   :   :   :
 bf 0 <------->   :
      :   :   :   :
 bf 1 :   <------->
      :   :   :   :

If it sends a frame to the browser between vsyncs 1 and 2, the browser doesn't
know if the frame is meant to be displayed at vsync 2 or 3.

Probably adding the BeginFrame timing data to CompositorFrameMetadata would be
enough to fix this.

I'm also note sure how this would work with input event batching.

https://codereview.chromium.org/22354007/diff/1/cc/output/output_surface.cc
File cc/output/output_surface.cc (right):

https://codereview.chromium.org/22354007/diff/1/cc/output/output_surface.cc#n...
cc/output/output_surface.cc:232: if (consecutive_missed_deadlines_) {
I think the interaction between CheckForRetroactiveBeginFrame and
RetroactiveBeginFrameDeadline is getting confusing. Could we simplify this so
that we adjust the deadlines going into skipped_begin_frame_args_ make sense
w.r.t. DefaultRetroactiveBeginFramePeriod()? That way we could always just pick
the oldest skipped BeginFrame whose deadline hasn't passed.

[mithro-old, 2014-05-01 03:03:05]

It looks like this CL is quite old but in the near future I'd like to look at
something like this. Adding myself as a reviewer so this doesn't get lost.

Tim

On 2013/08/13 16:44:08, Sami wrote:
> Hooray for better pipelining :) Did you have some specific case where this
helps
> or is this more speculative?
> 
> I think one potential problem here is that the browser no longer knows which
> outgoing BeginFrame corresponds to which incoming frame from the renderer
> (unless I missed something). Say the renderer has two BeginFrames like this:
> 
>       0   1   2   3  vsync
>       +---+---+---+-->
>       :   :   :   :
>  bf 0 <------->   :
>       :   :   :   :
>  bf 1 :   <------->
>       :   :   :   :
> 
> If it sends a frame to the browser between vsyncs 1 and 2, the browser doesn't
> know if the frame is meant to be displayed at vsync 2 or 3.
> 
> Probably adding the BeginFrame timing data to CompositorFrameMetadata would be
> enough to fix this.
> 
> I'm also note sure how this would work with input event batching.
> 
> https://codereview.chromium.org/22354007/diff/1/cc/output/output_surface.cc
> File cc/output/output_surface.cc (right):
> 
>
https://codereview.chromium.org/22354007/diff/1/cc/output/output_surface.cc#n...
> cc/output/output_surface.cc:232: if (consecutive_missed_deadlines_) {
> I think the interaction between CheckForRetroactiveBeginFrame and
> RetroactiveBeginFrameDeadline is getting confusing. Could we simplify this so
> that we adjust the deadlines going into skipped_begin_frame_args_ make sense
> w.r.t. DefaultRetroactiveBeginFramePeriod()? That way we could always just
pick
> the oldest skipped BeginFrame whose deadline hasn't passed.

[mithro-old, 2014-12-19 06:05:44]

Probably worth closing this?