Remove a frame of delay on main-thread FlingStart. [2nd land]

third_party/WebKit/Source/web/WebViewImpl.cpp

Index: third_party/WebKit/Source/web/WebViewImpl.cpp
diff --git a/third_party/WebKit/Source/web/WebViewImpl.cpp b/third_party/WebKit/Source/web/WebViewImpl.cpp
index 12e2e3b5158be4287dad2dbcdbe675b124fe4413..f6a890a5ba39f4bbe686b9d61f9d09263f0dfebb 100644
--- a/third_party/WebKit/Source/web/WebViewImpl.cpp
+++ b/third_party/WebKit/Source/web/WebViewImpl.cpp
@@ -699,8 +699,8 @@ WebInputEventResult WebViewImpl::HandleGestureEvent(
                             event.data.fling_start.velocity_y),
               WebSize());
       DCHECK(fling_curve);
-      gesture_animation_ = WebActiveGestureAnimation::CreateAtAnimationStart(

[dtapuska, 2017/05/31 00:53:11]

Do we want this to be the event creation time or Now()?

It seems that if we have a janky main thread you could end up missing a few
frames of the fling animation. Is that anticipated?

[aelias_OOO_until_Jul13, 2017/05/31 01:07:06]

My rule of thumb is that in cases of jank during animations, it's best to
eventually recover to the same position as if the jank had never happened
(preserving animation rate).  That argues for using the event timestamp.  This
is consistent with what happens if the main thread is janky after the animation
has already started, and it's also consistent with what impl-thread FlingStart
does (it uses event timestamp, not Now).

-          std::move(fling_curve), this);
+      gesture_animation_ = WebActiveGestureAnimation::CreateWithTimeOffset(
+          std::move(fling_curve), this, event.TimeStampSeconds());
       MainFrameImpl()->FrameWidget()->ScheduleAnimation();
       event_result = WebInputEventResult::kHandledSystem;