touch-event queue: Add a touch-event queue for all platforms.

touch-event queue: Add a touch-event queue for all platforms.

This touch-event queue will allow removing the touch-event queue in the
ui::gesture-recognizer, and asynchronous event processing (ui::ER_ASYNC) in
ui::event-dispatcher. This queue will also allow throttling/coalescing touch
events across all platforms.

BUG=138153, 110231
TBR=avi@chromium.org (for .gypi and content/port)

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=162510

[sadrul, 2012-10-16 22:46:48]

Hi! This is the first step towards implementing the touch-event queue that is
used in all platforms. The queue in this patch is deliberately small and simple,
since the main goal of this patch is to change the way touch-events are sent
from a RenderWidgetHostView to RenderWidget over IPC, and the corresponding ACKs
from RenderWidget to RenderWidgetHostView.

The next step (in this CL: http://codereview.chromium.org/11188012/) contains
the meat of the change: it adds touch-event coalescing, gets rid of the queue
from the gesture-recognizer etc. I split it into these two CLs to hopefully make
the reviews easier.

[aelias_OOO_until_Jul13, 2012-10-16 23:28:37]

Nice progress, thanks.

http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_impl.cc:1061:
touch_event_queue_->QueueEvent(touch_event);
RenderWidgetHost is not doing anything here except bouncing the event to the
queue.  And the "Immediately" method above makes an API that consistent with the
other kinds of events.

I'm thinking touch-event senders should be changed to talk directly to the
queue.  Then you wouldn't need to change RWH::ForwardTouchEvent.  Maybe RWH can
have a public getter method returning a pointer to the queue?

[sadrul, 2012-10-16 23:49:14]

http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host_impl.cc:1061:
touch_event_queue_->QueueEvent(touch_event);
On 2012/10/16 23:28:38, aelias wrote:
> RenderWidgetHost is not doing anything here except bouncing the event to the
> queue.  And the "Immediately" method above makes an API that consistent with
the
> other kinds of events.
> 
> I'm thinking touch-event senders should be changed to talk directly to the
> queue.  Then you wouldn't need to change RWH::ForwardTouchEvent.  Maybe RWH
can
> have a public getter method returning a pointer to the queue?

I actually considered doing something similar at first. But I thought it would
be better to keep the interaction between RWHV and RWH mostly unchanged, and
hide the queueing from the different RWHVs.

The ForwardTouchEvent/Immediately pair of functions are meant to be similar to
the ForwardGestureEvent/Immediately pair of functions, which do similar things
(throttles/coalesces events as appropriate), so I feel like this is more
consistent. In these cases, ForwardXXXEvent is the real API, and the Immediately
version is supposed to be used by the TouchEventQueue/GestureEventFilter as
appropriate, but since it is not possible to expose these 'Immediately'
functions without exposing all of the other privates in RWH, they became part of
the public API.

(Arguably, ForwardWheelEvent can also be split into two to be similar since it
also does throttling/coalescing).

[rjkroege, 2012-10-17 16:02:56]

On 2012/10/16 23:49:14, sadrul wrote:
>
http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
> File content/browser/renderer_host/render_widget_host_impl.cc (right):
> 
>
http://codereview.chromium.org/11148008/diff/5001/content/browser/renderer_ho...
> content/browser/renderer_host/render_widget_host_impl.cc:1061:
> touch_event_queue_->QueueEvent(touch_event);
> On 2012/10/16 23:28:38, aelias wrote:
> > RenderWidgetHost is not doing anything here except bouncing the event to the
> > queue.  And the "Immediately" method above makes an API that consistent with
> the
> > other kinds of events.
> > 
> > I'm thinking touch-event senders should be changed to talk directly to the
> > queue.  Then you wouldn't need to change RWH::ForwardTouchEvent.  Maybe RWH
> can
> > have a public getter method returning a pointer to the queue?
> 
> I actually considered doing something similar at first. But I thought it would
> be better to keep the interaction between RWHV and RWH mostly unchanged, and
> hide the queueing from the different RWHVs.
> 
> The ForwardTouchEvent/Immediately pair of functions are meant to be similar to
> the ForwardGestureEvent/Immediately pair of functions, which do similar things
> (throttles/coalesces events as appropriate), so I feel like this is more
> consistent. 

I am imagining that the gesture event filter should be re-factored at some
point. We could have a base event class with a sequence of filters. I was
thinking of making this look like UNIX sysv streams sort of. 

> In these cases, ForwardXXXEvent is the real API, and the Immediately
> version is supposed to be used by the TouchEventQueue/GestureEventFilter as
> appropriate, but since it is not possible to expose these 'Immediately'
> functions without exposing all of the other privates in RWH, they became part
of
> the public API.
> 
> (Arguably, ForwardWheelEvent can also be split into two to be similar since it
> also does throttling/coalescing).

yes. The wheel events should be pushed through the same infrastructure. In a
different CL.

[rjkroege, 2012-10-17 16:03:09]

lgtm.

[aelias_OOO_until_Jul13, 2012-10-17 18:16:55]

lgtm

[sadrul, 2012-10-17 18:29:37]

Thanks for the quick reviews! :)

+avi for content_browser.gypi and content/port changes.

[sadrul, 2012-10-17 20:18:26]

TBR'ing the changes in content_browser.gypi and content/port