cc: Handle future timebases properly in DelayBasedTimeSource

cc: Handle future timebases properly in DelayBasedTimeSource

The existing code didn't anticipate negative values for
intervals_elapsed, which would round up towards 0 instead
of down towards 0 and cause the next frame to be posted
more than 1 vsync away.

This primarly cropped up on Windows machines, but only
for certain configurations.

BUG=262437
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=217723

[brianderson, 2013-08-14 22:09:54]

Nat or Jared, can I get a quick review of this patch?

After this lands on master, I need to cherry-pick it to M30.

[nduca, 2013-08-14 22:33:40]

lgtm

[commit-bot: I haz the power, 2013-08-14 22:34:36]

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

[jdduke (slow), 2013-08-14 22:39:36]

https://codereview.chromium.org/22887010/diff/4001/cc/scheduler/delay_based_t...
File cc/scheduler/delay_based_time_source.cc (right):

https://codereview.chromium.org/22887010/diff/4001/cc/scheduler/delay_based_t...
cc/scheduler/delay_based_time_source.cc:200: if (next_parameters_.tick_target <
now) {
To make this a bit easier to read, what about defining something like:

base::TimeDelta time_since_tick_target = now - next_parameters_.tick_target;
if (time_since_tick_target > TimeDelta())
...

and re-using that value in the two computations?  I'm not incredibly familiar
with the context but the rest seems reasonable.  Do we have any utilities for
division rounding?

[jdduke (slow), 2013-08-14 22:40:04]

On 2013/08/14 22:39:36, jdduke wrote:
>
https://codereview.chromium.org/22887010/diff/4001/cc/scheduler/delay_based_t...
> File cc/scheduler/delay_based_time_source.cc (right):
> 
>
https://codereview.chromium.org/22887010/diff/4001/cc/scheduler/delay_based_t...
> cc/scheduler/delay_based_time_source.cc:200: if (next_parameters_.tick_target
<
> now) {
> To make this a bit easier to read, what about defining something like:
> 
> base::TimeDelta time_since_tick_target = now - next_parameters_.tick_target;
> if (time_since_tick_target > TimeDelta())
> ...
> 
> and re-using that value in the two computations?  I'm not incredibly familiar
> with the context but the rest seems reasonable.  Do we have any utilities for
> division rounding?

Too late :)

[commit-bot: I haz the power, 2013-08-15 01:22:05]

Change committed as 217723