Don't block the browser on FlingCancel acks.

Don't block the browser on FlingCancel acks.

RenderWidgetHostImpl was queueing up further gesture events until
receiving a FlingCancelAck. However, FlingCancel events often
propagate right down to the WebKit thread (the compositor can't
handle the event unless it's in the middle of a fling), so the
browser ended up blocking on WebKit.

This patch makes FlingCancel non-blocking. There should be no
visible change in behaviour except lower latency for flings.

BUG=136167
TEST=Browser tests, manual testing on Android

[Iain Merrick, 2012-07-06 14:50:58]

I'm not sure this is the best approach, but it seems to work fairly well on
Android.

It might be better to push all this coalescing logic down into the renderer,
closer to where the events are actually processed, but that's a much bigger
change.

[rjkroege, 2012-07-09 15:16:48]

I am not sure that this is the right way to do this.

GFCs are nops in upstream WebKit unless there is a fling in progress. We could
consider always handling GFCs on the compositor thread if the WebKit thread told
the compositor when it started and ended handling a fling?

[Iain Merrick, 2012-07-16 14:29:20]

Sorry for the delay in replying, I just got back from holiday.

How can we decide which is the best approach? Your suggestion does sound like it
would work. But it sounds a little suspicious to me because it means duplicating
state between the WebKit thread and compositor thread, which makes the code that
much more complex. (Admittedly we're already doing that a lot, though!)

My approach also increases complexity by treating FlingCancel as a special case,
but it's localized in one place, and I think it's a valid special case --
FlingCancel is an idempotent fire-and-forget operation, so it seems reasonable
for it to be fully asynchronous.

What do you think?

[Iain Merrick, 2012-07-24 14:51:16]

rjkoege and I discussed this offline. We need a general solution for both
ChromeOS and Android. A design doc is in the works.