NOT FOR LANDING - [WebView] Allow fling animation via the LayerScrollOffsetDelegate

android_webview/browser/browser_view_renderer.cc

Index: android_webview/browser/browser_view_renderer.cc
diff --git a/android_webview/browser/browser_view_renderer.cc b/android_webview/browser/browser_view_renderer.cc
index cad7c5b96b7b331180b02aa2f79af3e91eff5daf..ccedd6b373ad0857dbac68ec46d98e7e8764c686 100644
--- a/android_webview/browser/browser_view_renderer.cc
+++ b/android_webview/browser/browser_view_renderer.cc
@@ -617,6 +617,21 @@ void BrowserViewRenderer::SetRootLayerScrollableSize(
   client_->SetContentsSize(scrollable_size);
 }
 
+void BrowserViewRenderer::SetNeedsAnimate(const AnimationCallback& animation) {
+  if (!ui_task_runner_->BelongsToCurrentThread()) {
+    // This is scary, must ensure |animation| is called on the right thread.
+    ui_task_runner_->PostTask(
+        FROM_HERE,
+        base::Bind(&BrowserViewRenderer::SetNeedsAnimate,
+                   ui_thread_weak_ptr_,
+                   animation));
+    return;
+  }
+  // TODO(jdduke): Implement.
+  // client_->Foo(); ??
+  // Stash the callback and wait for a call? Trigger an invalidate?

[mkosiba (inactive), 2014/05/15 13:48:51]

probably more like TODO(mkosiba): Implement. ;)

The implementation would be to stash the callback, invalidate and wait for a
call.

If a fling is active would we be getting a call to SetNeedsAnimate shortly after
(or immediately after) we call the AnimationCallback? (in other words should we
consider AnimationCallback one-shot?)

Is it bad for AnimationCallback to not be called at all? We could detect that
the embedder is suppressing computeScroll and somehow cancel the fling animation
I guess.

[jdduke (slow), 2014/05/15 14:15:43]

Yes, you get the |SetNeedsAnimate()| call either 1) When the fling is first
received and needs scheduling, or 2) You tick the fling (via the animation
callback), and the fling is still active, so it requests another update (in
which case |SetNeedsAnimate()| is called synchronously with respect to
animation.Run(...)). 

Also, we don't necessarily need to use an actual Callback, we could as easily
use an interface that we provide the offset delegate, but the callback approach
is pretty simple (though we'll want to make sure the weak ptr is still valid
before running? or does it to that automatically?).
The consequences of not calling this would simply be that the fling animation
has no effect.  There won't be any additional ticking; the fling will just lie
dormant in the InputHandlerProxy over its lifetime, and will get canceled by a
GestureFlingCancel at some point.  I guess the only reason to early-cancel would
be to prevent it being "boosted" with another fling, but in that case you'd be
suppressing the subsequent fling anyway?

[mkosiba (inactive), 2014/05/15 17:23:38]

ok, thanks for the explanation. sounds good.
callback is fine I think. It does the right thing - using weak ptr means the
callback doesn't do anything when you Run() or PostTask it.
Ok, in that case I don't think we need to do anything special. I was concerned
that if we never "finish" the fling CC will think we're running the fling
forever and thus will always be using bilinear filtering (or whatever we use
when IsExternalFlingActive is true).
It sounds like we'd get a GestureFlingCancel at some point anyway so this is
probably irrelevant.

+}
+
 void BrowserViewRenderer::DidOverscroll(gfx::Vector2dF accumulated_overscroll,
                                         gfx::Vector2dF latest_overscroll_delta,
                                         gfx::Vector2dF current_fling_velocity) {