[NOT FOR REVIEW] Patch demonstrating the changes required for browser side fling.

[NOT FOR REVIEW] Patch demonstrating the changes required for browser side fling.

BUG=none

[jdduke (slow), 2013-10-31 15:44:20]

https://codereview.chromium.org/45623005/diff/50001/webkit/child/fling_curve_...
File webkit/child/fling_curve_configuration.h (left):

https://codereview.chromium.org/45623005/diff/50001/webkit/child/fling_curve_...
webkit/child/fling_curve_configuration.h:1: // Copyright (c) 2013 The Chromium
Authors. All rights reserved.

I'm not sure we should be removing any of this from webkit/.  Blink still needs
the ability to create flings, no?  Particularly for non-Chromium platforms?  I
suppose if Chromium guarantees Blink never receives a GestureFlingStart, we're
OK, but that seems a little fishy... Do you have a CL for the Blink changes?

[varunjain, 2013-10-31 17:26:03]

https://codereview.chromium.org/45623005/diff/50001/webkit/child/fling_curve_...
File webkit/child/fling_curve_configuration.h (left):

https://codereview.chromium.org/45623005/diff/50001/webkit/child/fling_curve_...
webkit/child/fling_curve_configuration.h:1: // Copyright (c) 2013 The Chromium
Authors. All rights reserved.
On 2013/10/31 15:44:20, jdduke wrote:
> 
> I'm not sure we should be removing any of this from webkit/.  Blink still
needs
> the ability to create flings, no?  Particularly for non-Chromium platforms?  I
> suppose if Chromium guarantees Blink never receives a GestureFlingStart, we're
> OK, but that seems a little fishy... Do you have a CL for the Blink changes?

I dont have a patch for blink yet. But IIUC, non-Chromium platforms are expected
to interact with blink using content api. So as long as content is handling
fling, there is no lose of functionality?

[varunjain, 2013-11-05 20:11:13]

+everyone
This patch shows code changes for browser side fling. It adds Flinger in the
browser side that generates GestureScrollUpdates based on fling curves. The
fling curves are just moved from the renderer to the browser. But removing fling
from the renderer results in significant cleanup of renderer and cc code. It
also cleans up browser side gesture event filter and tap suppression code.

[jamesr, 2013-11-27 03:11:26]

How does this bind to the correct scrolling layer for touchscreen scrolls?

https://codereview.chromium.org/45623005/diff/50001/content/renderer/gpu/inpu...
File content/renderer/gpu/input_handler_proxy.cc (right):

https://codereview.chromium.org/45623005/diff/50001/content/renderer/gpu/inpu...
content/renderer/gpu/input_handler_proxy.cc:208: NOTREACHED();
you still have to hit test in order to bind to the correct layer for the fling,
don't you?

[jamesr, 2013-11-27 04:45:39]

I see, it just hit tests in GestureScrollBegin.  I don't think that you can
actually remove the external scroll logic, although perhaps there are other
changes in the android webview bindings here that I've missed.  I also don't see
how this handles fling cancels correctly in the case where the fling ends
because the target went away.  Does it just eat the next event regardless?

As for getting this landable I'd suggest adding a flag that generates
GestureScroll*** events in the browser and sends those down.  It'd be
transparent to the render process.  Then when you validate that it works you can
remove the renderer code.

[jdduke (slow), 2014-11-13 01:32:41]

jdduke@chromium.org changed reviewers:
- jdduke@chromium.org