Make it possible for the scroll offset delegate to intercept fling.

Make it possible for the scroll offset delegate to intercept fling.

Related Blink CL: https://codereview.chromium.org/14678013

This adds functionality so that the LayerScrollOffsetDelegate can
intercept the fling gesture.
This is so that the android_webview layer can handle the root layer
fling gestures on its own.

BUG=b/5006389
TESTS=cc_unittests

[mkosiba (inactive), 2013-05-10 16:40:10]

Hey James!
    Could you take a quick look at this CL and the associated
(http://crrev.com/14678013)?
    Is this approach acceptable? The (slightly uglier IMO) alternative is to
cache the last gesture event in the android_webview layer and get the fling
velocity from there.

[jamesr, 2013-05-10 16:53:19]

Why don't you just handle the event yourself in android_webview?  This doesn't
seem good.

[mkosiba (inactive), 2013-05-10 17:02:16]

On 2013/05/10 16:53:19, jamesr wrote:
> Why don't you just handle the event yourself in android_webview?  This doesn't
> seem good.

I still want CC to handle fling for sub-layers. How should I find out whether
the gesture is intended for the root layer or not?

[jamesr, 2013-05-10 18:13:21]

On 2013/05/10 17:02:16, mkosiba wrote:
> On 2013/05/10 16:53:19, jamesr wrote:
> > Why don't you just handle the event yourself in android_webview?  This
doesn't
> > seem good.
> 
> I still want CC to handle fling for sub-layers. How should I find out whether
> the gesture is intended for the root layer or not?

You will have to tell the compositor not to handle flings on the root layer. 
Currently cc/ has the ability to tell it that a particular layer can or can't be
scrolled - see
https://code.google.com/p/chromium/codesearch#chromium/src/cc/layers/layer.h&...
- but you'll have to add something more specifically for fling.

[mkosiba (inactive), 2013-05-10 19:54:41]

On 2013/05/10 18:13:21, jamesr wrote:
> On 2013/05/10 17:02:16, mkosiba wrote:
> > On 2013/05/10 16:53:19, jamesr wrote:
> > > Why don't you just handle the event yourself in android_webview?  This
> doesn't
> > > seem good.
> > 
> > I still want CC to handle fling for sub-layers. How should I find out
whether
> > the gesture is intended for the root layer or not?
> 
> You will have to tell the compositor not to handle flings on the root layer. 
> Currently cc/ has the ability to tell it that a particular layer can or can't
be
> scrolled - see
>
https://code.google.com/p/chromium/codesearch#chromium/src/cc/layers/layer.h&...
> - but you'll have to add something more specifically for fling.

But how would I know whether the root layer fling is being not handled by CC
because
of this new setting and not for other reasons (like that the fling gesture hit a
fixed
position element)?
The input handler returns 3 statuses - Started, Ignored and OnMainThread. I'm
probably
missing something but how would I determine whether the fling was ignored only
due to
the new setting based on the information I get from the
WebCompositorInputHandlerClient?

[jamesr, 2013-05-10 20:12:37]

I think it's easier to think about this in terms of the browser<->renderer
interface (even though in android webview there isn't a process split, etc). 
The generic input API works like this:

Browser process sends an input event to the render process via
InputMsg_HandleInputEvent

Renderer process handles this input event (possibly in the compositor thread,
possibly on the main thread) and then sends a reply via
InputHostMsg_HandleInputEvent_ACK with a content::InputEventAckState which is
one of the following values:

  INPUT_EVENT_ACK_STATE_UNKNOWN,
  INPUT_EVENT_ACK_STATE_CONSUMED,
  INPUT_EVENT_ACK_STATE_NOT_CONSUMED,
  INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS,

If the render process handles the fling itself, it will return IEAS_CONSUMED. 
If there is nothing in the render process that is flingable at all, it will
return IEAS_NO_CONSUMER_EXISTS.  If there is a (potential) consumer, but the
render process can't handle the fling itself, it will return IEAS_NOT_CONSUMED. 
Thus for android_webview an ACK status of CONSUMED or NO_CONSUMER_EXISTS means
that the gesture went to a sublayer or should be ignored completely, but a
status of NOT_CONSUMED means the fling is valid and can be handled by the
android_webview code.

In terms of the cc::InputHandler status, you should configure the compositor
such that a fling targetting at the root layer returns ScrollOnMainThread and
then make sure that on the main thread the fling is returned without being
marked as processed.

[mkosiba (inactive), 2013-05-10 20:44:29]

On 2013/05/10 20:12:37, jamesr wrote:
> I think it's easier to think about this in terms of the browser<->renderer
> interface (even though in android webview there isn't a process split, etc). 
> The generic input API works like this:
> 
> Browser process sends an input event to the render process via
> InputMsg_HandleInputEvent
> 
> Renderer process handles this input event (possibly in the compositor thread,
> possibly on the main thread) and then sends a reply via
> InputHostMsg_HandleInputEvent_ACK with a content::InputEventAckState which is
> one of the following values:
> 
>   INPUT_EVENT_ACK_STATE_UNKNOWN,
>   INPUT_EVENT_ACK_STATE_CONSUMED,
>   INPUT_EVENT_ACK_STATE_NOT_CONSUMED,
>   INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS,
> 
> If the render process handles the fling itself, it will return IEAS_CONSUMED. 
> If there is nothing in the render process that is flingable at all, it will
> return IEAS_NO_CONSUMER_EXISTS.  If there is a (potential) consumer, but the
> render process can't handle the fling itself, it will return
IEAS_NOT_CONSUMED. 
> Thus for android_webview an ACK status of CONSUMED or NO_CONSUMER_EXISTS means
> that the gesture went to a sublayer or should be ignored completely, but a
> status of NOT_CONSUMED means the fling is valid and can be handled by the
> android_webview code.
> 
> In terms of the cc::InputHandler status, you should configure the compositor
> such that a fling targetting at the root layer returns ScrollOnMainThread and
> then make sure that on the main thread the fling is returned without being
> marked as processed.

Thanks for the detailed explanation! Now your previous comments make a lot
more sense to me :)
I'll send out an updated CL next week.

[mkosiba (inactive), 2013-05-14 17:59:29]

James,
   I tried to implement the approach you've outlined and have two questions:

On 2013/05/10 20:12:37, jamesr wrote:
> In terms of the cc::InputHandler status, you should configure the compositor
> such that a fling targetting at the root layer returns ScrollOnMainThread and
> then make sure that on the main thread the fling is returned without being
> marked as processed.

1) Doesn't this mean a latency increase for fling gestures processed this way?
It looks like we already know whether we want to handle the gesture on the UI
thread based on information we have available on the impl thread, so is the hop
to the renderer thread really necessary?

2) As for making the main thread ignore the fling - I had a look at
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
. It seems like the fling gesture is converted to an animation (and then a
series of scrollBy's) pretty early, so I can't easily delegate the gesture to
the WebLayer to check whether it should be ignored or not. 
I'm guessing I'd have to do a hit test to see which node the gesture is headed
to, but based on the hit test result I can't quite figure out how to check
whether the resulting Node belongs to the root layer. Is it sufficient to check
that the Node's renderer is the RenderView?

[jamesr, 2013-05-14 20:54:50]

> James,
>    I tried to implement the approach you've outlined and have two questions:
> 
> On 2013/05/10 20:12:37, jamesr wrote:
> > In terms of the cc::InputHandler status, you should configure the compositor
> > such that a fling targetting at the root layer returns ScrollOnMainThread
and
> > then make sure that on the main thread the fling is returned without being
> > marked as processed.
> 
> 1) Doesn't this mean a latency increase for fling gestures processed this way?
> It looks like we already know whether we want to handle the gesture on the UI
> thread based on information we have available on the impl thread, so is the
hop
> to the renderer thread really necessary?

If the main frame is scrollable but can't be scrolled on the impl thread, the
fling has to go to the main thread doesn't it?  If you know that the main thread
doesn't need to process the event but it is valid to fling, you can return
ScrollIgnored from the input handler which will map to
INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS sent directly from the impl thread.

What's the behavior you want for the case of forced main thread scrolling?  If
you want to still handle the fling up in the android_webview code, then you
could make the setting on the root layer always pass the fling back up without
going through the main thread.

[mkosiba (inactive), 2013-05-15 13:22:35]

On Tue, May 14, 2013 at 9:54 PM, <jamesr@chromium.org> wrote:

> James,
>>     I tried to implement the approach you've outlined and have two
>> questions:
>>
>
>  On 2013/05/10 20:12:37, jamesr wrote:
>> > In terms of the cc::InputHandler status, you should configure the
>> compositor
>> > such that a fling targetting at the root layer returns
>> ScrollOnMainThread
>>
> and
>
>> > then make sure that on the main thread the fling is returned without
>> being
>> > marked as processed.
>>
>
>  1) Doesn't this mean a latency increase for fling gestures processed this
>> way?
>> It looks like we already know whether we want to handle the gesture on
>> the UI
>> thread based on information we have available on the impl thread, so is
>> the
>>
> hop
>
>> to the renderer thread really necessary?
>>
>
> If the main frame is scrollable but can't be scrolled on the impl thread,
> the
> fling has to go to the main thread doesn't it?  If you know that the main
> thread
> doesn't need to process the event but it is valid to fling, you can return
> ScrollIgnored from the input handler which will map to
> INPUT_EVENT_ACK_STATE_NO_**CONSUMER_EXISTS sent directly from the impl
> thread.
>

I thought in this case I'd want the impl thread to send back a IEAS_NOT_**
CONSUMED. Doesn't IEAS_NO_**CONSUMER_EXISTS mean that there isn't anything
to fling/scroll ?


>
> What's the behavior you want for the case of forced main thread scrolling?
>  If
> you want to still handle the fling up in the android_webview code, then you
> could make the setting on the root layer always pass the fling back up
> without
> going through the main thread.
>

I think that for forced main thread scrolling we'd want to let the main
thread handle the fling, so making the impl thread return the ACK is the
way to go, right?