Coalesce async touch move events until the ack back from render

content/browser/renderer_host/input/input_router_impl.cc

Index: content/browser/renderer_host/input/input_router_impl.cc
diff --git a/content/browser/renderer_host/input/input_router_impl.cc b/content/browser/renderer_host/input/input_router_impl.cc
index 54bf892014c80b6884e624cdcdaac312c0817e46..8b2456c4f8b532525d6cac4347c5ba2a786e356e 100644
--- a/content/browser/renderer_host/input/input_router_impl.cc
+++ b/content/browser/renderer_host/input/input_router_impl.cc
@@ -347,13 +347,17 @@ void InputRouterImpl::OfferToHandlers(const WebInputEvent& input_event,
   // Touch events should always indicate in the event whether they are
   // cancelable (respect ACK disposition) or not.
   bool ignores_ack = WebInputEventTraits::IgnoresAckDisposition(input_event);
+  bool touch_move_aysnc = false;
   if (WebInputEvent::isTouchEventType(input_event.type)) {
     const WebTouchEvent& touch = static_cast<const WebTouchEvent&>(input_event);
-    DCHECK_NE(ignores_ack, !!touch.cancelable);
+    touch_move_aysnc = !touch.cancelable;
+    if(touch.type !=  WebInputEvent::TouchMove)
+      DCHECK_NE(ignores_ack, touch.cancelable);
   }
 
-  // If we don't care about the ack disposition, send the ack immediately.
-  if (ignores_ack) {
+  // If we don't care about the ack disposition, or it is an async touchmove
+  // event, send the ack immediately.
+  if (ignores_ack || touch_move_aysnc) {
     ProcessInputEventAck(input_event.type,
                          INPUT_EVENT_ACK_STATE_IGNORED,
                          latency_info,
@@ -418,6 +422,14 @@ void InputRouterImpl::OnInputEventAck(
     OnDidOverscroll(*ack.overscroll);
   }
 
+  // When we receive ACK from render for async touchmove events, we tell
+  // touch_event_queue right away so it will send out the next touch move in
+  // the queue.
+  if (ack.type == WebInputEvent::TouchMove &&

[jdduke (slow), 2015/03/11 22:37:10]

This seems like it could be racy. When a scroll sequence transitions from being
consumed to unconsumed (changing the value of IsSendingTouchEventsAsync()), it
seems like we could incorrectly mark a touchmove ack as sync/async when that may
not have been the case?

+      touch_event_queue_.IsSendingTouchEventsAsync()) {
+    touch_event_queue_.ReceiveAsyncTouchMoveAck();

[jdduke (slow), 2015/03/11 22:37:10]

I'm a little concerned about the special interaction here between the
TouchEventQueue and the InputRouter.

I wonder if there's any way we could achieve the same result without changing
the InputRouter at all? This would probably mean that, whenever we forward the
async event, we put it in a special async queue separate from the regular queue
(in the TouchEventQueue). That way, it doesn't block the regular queue, and we
can use the async queue to filter out acks as they arrive.  The downside there
is that we'll need a way to map between acks and touches, as it's possible to
get out-of-order acks. Sadly, I think we may need something like that anyway if
we're to achieve nonblocking behavior.

+  }
+
   ProcessInputEventAck(ack.type, ack.state, ack.latency, RENDERER);
   // WARNING: |this| may be deleted at this point.