Fix smooth scroll animation flake on janky pages

cc/animation/scroll_offset_animations_impl.cc

Index: cc/animation/scroll_offset_animations_impl.cc
diff --git a/cc/animation/scroll_offset_animations_impl.cc b/cc/animation/scroll_offset_animations_impl.cc
index f49bb9d54f7a3e3f32fd9d64241f97be9e593941..f72a2d80fa59531bef442f2988cc35bd91535451 100644
--- a/cc/animation/scroll_offset_animations_impl.cc
+++ b/cc/animation/scroll_offset_animations_impl.cc
@@ -86,9 +86,14 @@ bool ScrollOffsetAnimationsImpl::ScrollAnimationUpdateTarget(
   new_target.SetToMax(gfx::ScrollOffset());
   new_target.SetToMin(max_scroll_offset);
 
-  curve->UpdateTarget(
-      animation->TrimTimeToCurrentIteration(frame_monotonic_time).InSecondsF(),
-      new_target);
+  // TODO(ymalik): Animation::TrimTimeToCurrentIteration should probably check
+  // for run_state == Animation::WAITING_FOR_TARGET_AVAILABILITY.

[ajuma, 2016/08/18 14:16:25]

Yeah, Animation::ConvertToActiveTime should probably treat this run state the
same as Animation::STARTING. But that can be done in a follow-up.

[ymalik, 2016/08/18 17:23:33]

Yeah. I tried to do it in this CL and a bunch of tests fail. This is because
Animation::WAITING_FOR_TARGET_AVAILABILTY is the default value, and a lot of the
tests are simply checking expectations after calling TrimTimeToCurrentIteration
without changing the default run state of the animation (so it returns 0 and not
their expectation).

+  base::TimeDelta trimmed =
+      animation->run_state() == Animation::WAITING_FOR_TARGET_AVAILABILITY
+          ? base::TimeDelta()
+          : animation->TrimTimeToCurrentIteration(frame_monotonic_time);
+
+  curve->UpdateTarget(trimmed.InSecondsF(), new_target);

[ymalik, 2016/08/18 07:34:20]

The observed failure mode is that when you do two mouse wheel ticks on a janky
page, the first one would instant scroll and the second one would smooth scroll.
Here is what's happening:

The first tick will create a new scroll offset animation in the
Animation::WAITING_FOR_TARGET_AVAILABILITY state. Before a call to UpdateTarget
can put the animation in Animation::STARTING state, we get the scroll from the
second mouse wheel tick. The second tick will call
ScrollOffsetAnimationCurve::UpdateTarget with an incorrect delta (delta should
be 0 because the first animation hasn't ticked yet). This is because the call to
Animation::TrimTimeToCurrentIteration only returns 0 if the animation is in
Animation::STARTING state (see
https://cs.chromium.org/chromium/src/cc/animation/animation.cc?rcl=1471447605...).

 
   return true;
 }