Change LayerHostImpl to use frame time from BeginFrameArgs rather than ::Now()

BeginFrameArgs are sent for every new animation frame and contain the frame time that should be used for animating.

When background ticking, we override the frame time with the output of our TimeSource. This should be replaced in the future with a BeginBackgroundFrame type system mirroring BeginFrame.

BUG=345459

[mithro-old, 2014-02-28 00:33:38]

Need to figure out background animation ticking.

----------------------------------------------

void ThreadProxy::UpdateBackgroundAnimateTicking() {
  bool should_background_tick =
      !impl().scheduler->WillDrawIfNeeded() &&
      impl().layer_tree_host_impl->active_tree()->root_layer();
  impl().layer_tree_host_impl->UpdateBackgroundAnimateTicking(
      should_background_tick);
  if (should_background_tick)
    impl().animations_frozen_until_next_draw = false;
}

----------------------------------------------

[mithro-old, 2014-03-11 15:35:23]

Can you all please take another look at this patch?

I think I've fixed the background ticking stuff, but I'm sure it still has other
issues.

[danakj, 2014-03-11 18:32:35]

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:172:
layer_tree_host_impl_->OverrideCurrentFrameTime(
This should be above UpdateDrawProps/ManageTiles.

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:2509: CurrentFrameTimeTicks(),
distance_to_scrollbar / device_scale_factor_);
What happens if you get input here and you're not in a BeginImplFrame yet, or
the impl frame takes multiple vsyncs? Is this going to cause any regressions?
+aelias for thoughts on CurrentPhysical -> CurrentFrame time.

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl_unittest.cc:1174:
OverrideCurrentFrameTime(fake_now);
Just make the tests call this directly?

https://codereview.chromium.org/184023002/diff/30001/cc/trees/single_thread_p...
File cc/trees/single_thread_proxy.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/single_thread_p...
cc/trees/single_thread_proxy.cc:535:
layer_tree_host_impl_->OverrideCurrentFrameTime(frame_begin_time);
This is really late, we'll have generated a frame for 1 time, then draw with
another time. I think this should be at the top of CommitAndComposite().

https://codereview.chromium.org/184023002/diff/30001/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1390: void ThreadProxy::DidBeginImplFrameDeadline() {
Can this method go away?

https://codereview.chromium.org/184023002/diff/30001/cc/trees/thread_proxy.cc...
cc/trees/thread_proxy.cc:1629: base::TimeTicks now = gfx::FrameTime::Now();
Why are you using Now here?

[mithro-old, 2014-03-20 03:31:54]

Hi aelias,

Dana suggested that you would be a good person to look at this CL and how it
effects input.

Would you be able to take a look or suggest someone else who is better suited?

Thank you,

Tim 'mithro' Ansell

[aelias_OOO_until_Jul13, 2014-03-21 01:37:43]

Hmm, it looks to me like every place in this where you changed physical time to
frame time in this patch should actually remain physical time.  The choice of
physical time in those places actually wasn't an accident.  

It's important to keep in mind that the timer goes quiescent when there's no
need to animate, for battery usage reasons.  That means an input event can
suddenly come in when the frame time hasn't been updated in a long time, and use
an ancient time stamp by accident.  For that reason, input-related things all
use physical time.  As a more general principle, to avoid unexpected glitches,
frame time should only be used in places where we know for certain that we're in
the middle of an animation.  (At least, that's how we've been doing things so
far -- I'm open to alternate schemes that might avoid the timer quiescence
problem, as long as scrollbar fade scheduling on Android is tested carefully.)

https://codereview.chromium.org/184023002/diff/30001/cc/layers/layer_impl.cc
File cc/layers/layer_impl.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/layers/layer_impl.cc#...
cc/layers/layer_impl.cc:1288: layer_tree_impl_->CurrentFrameTimeTicks());
physical time

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:2479:
animation_controller->DidMouseMoveOffScrollbar(CurrentFrameTimeTicks());
physical time

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:2523: CurrentFrameTimeTicks(), 0);
physical time

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:2839:
StartScrollbarAnimationRecursive(RootLayer(), CurrentFrameTimeTicks());
This is another thing I specifically changed to physical time in
https://chromiumcodereview.appspot.com/16925007

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_impl.cc
File cc/trees/layer_tree_impl.cc (right):

https://codereview.chromium.org/184023002/diff/30001/cc/trees/layer_tree_impl...
cc/trees/layer_tree_impl.cc:259: ->DidScrollGestureEnd(CurrentFrameTimeTicks());
physical time.  Note that I specifically changed this line from frame time to
physical time to fix a regression in this patch:
https://chromiumcodereview.appspot.com/16925007

[aelias_OOO_until_Jul13, 2014-03-25 07:40:19]

FYI, I posted an alternative way to remove CurrentPhysicalTimeTicks that
addresses my concerns: https://codereview.chromium.org/210793002/