[Android] Perform eager gesture recognition on MotionEvents

content/browser/renderer_host/input/touch_to_gesture_queue.h

Index: content/browser/renderer_host/input/touch_to_gesture_queue.h
diff --git a/content/browser/renderer_host/input/touch_to_gesture_queue.h b/content/browser/renderer_host/input/touch_to_gesture_queue.h
new file mode 100644
index 0000000000000000000000000000000000000000..a762fd3f43c488d189e487c46fec2d2361fc96b3
--- /dev/null
+++ b/content/browser/renderer_host/input/touch_to_gesture_queue.h
@@ -0,0 +1,77 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_BROWSER_RENDERER_HOST_INPUT_TOUCH_TO_GESTURE_QUEUE_H_
+#define CONTENT_BROWSER_RENDERER_HOST_INPUT_TOUCH_TO_GESTURE_QUEUE_H_
+
+#include <deque>
+
+#include "content/common/content_export.h"
+#include "content/port/common/input_event_ack_state.h"
+#include "third_party/WebKit/public/web/WebInputEvent.h"
+
+namespace content {
+
+class TouchToGestureQueueClient {
+ public:
+  virtual ~TouchToGestureQueueClient() {}
+  virtual void ForwardTouchEvent(const blink::WebTouchEvent&) = 0;

[tdresser, 2014/01/14 16:25:30]

I think it may be cleaner to do the touch event dispatch outside of the
TouchToGestureQueue. If you dispatch the touch events before passing the touch
events to the TTGQ, you don't need to store the touch events in the TTGQ at all.

I guess there's also an advantage in unifying the flow of touch and gesture
events, so I'm open to either solution.

[jdduke (slow), 2014/01/14 23:24:03]

The main reason I did it this way was because of the
|OnTouchEventHandling{Begin,End]| methods, requiring that we delay sending the
touch until we've assembled all of its gestures (as the touch ack may be
synchronous).

If we can all agree that PD'ed touchmove's within the touch slop region will
prevent both tapping and scrolling, then I think we can go ahead with forwarding
the touches immediately.

[tdresser, 2014/01/15 13:43:08]

I was under the impression that this solution would already only work if PD'ed
touchmoves within the touch slop region would prevent tapping and scrolling. Is
that incorrect?

[jdduke (slow), 2014/01/15 20:36:36]

In it's current form, that's very much correct.  We'd have to make some
(non-trivial) changes to make it support touch slop suppression (in short, we'd
have to hold touch events until the initial TouchStart ack is received, getting
us into the business of touch queueing which I'd prefer to avoid).   However,
per our discussion, I'm inclined not to support that at all, unless we find in
the future that we absolutely need it.

+  virtual void ForwardGestureEvent(const blink::WebGestureEvent&) = 0;
+};
+
+class CONTENT_EXPORT TouchToGestureQueue {

[tdresser, 2014/01/14 16:25:30]

The names TouchToGesture, TouchToGestureSequence, and TouchToGestureSequence,
are a little confusing.

I think they might be a little clearer as TouchToGestures,
TouchToGesturesSequence, and TouchToGesturesQueue, though those aren't fantastic
names.

If we decide to stop storing touch events, this naming might get a bit simpler
too.

 

[jdduke (slow), 2014/01/14 23:24:03]

Let's just call it GestureEventQueue? To match TouchEventQueue?

[tdresser, 2014/01/15 13:43:08]

I like that name. I do think that TouchToGesture -> TouchToGestures would also
clarify matters.

+ public:
+  explicit TouchToGestureQueue(TouchToGestureQueueClient* client);
+  ~TouchToGestureQueue();
+
+  // TODO(jdduke): Refactor to take a touch event with a vector of gestures.

[tdresser, 2014/01/14 16:25:30]

Is it reasonable to perform this refactor before this lands? It would make
interaction with the TouchToGestureQueue a lot clearer.

[jdduke (slow), 2014/01/14 23:24:03]

We could.  With the way gestures are piped here (via callbacks), we'll need to
do the gesture "collecting" somewhere, but that could be offloaded to a wrapper
or even just the ContentViewCoreImpl for now, no need to clutter the interface
for something the caller should be doing.

[tdresser, 2014/01/15 13:43:08]

Aggregating the gestures in CVCI sounds like a good plan to me.

+  void OnTouchEventHandlingBegin(const blink::WebTouchEvent& event);
+  void OnGestureEvent(const blink::WebGestureEvent& event);
+  void OnTouchEventHandlingEnd();
+
+  void OnTouchEventAck(InputEventAckState ack_state);
+
+ private:
+  typedef std::deque<blink::WebGestureEvent> Gestures;
+
+  struct TouchToGesture {

[jdduke (slow), 2014/01/13 23:58:56]

These data structures aren't very optimized.  I'll likely have a fixed size
array for gestures per touch, and reserve a certain size upon creation of the
|TouchToGesture.sequence| array.

+    blink::WebTouchEvent touch;
+    Gestures gestures;
+  };
+
+  class TouchToGestureSequence {
+   public:
+    TouchToGestureSequence();
+    ~TouchToGestureSequence();
+
+    void Push(const blink::WebTouchEvent& event);
+    void Push(const blink::WebGestureEvent& event);
+    TouchToGesture OnTouchEventAck(InputEventAckState ack_state);
+    bool IsGestureAllowed() const;
+    bool IsEmpty() const;
+    const blink::WebTouchEvent& LastTouch() const;
+
+   private:
+    std::deque<TouchToGesture> sequence;
+    InputEventAckState ack_state;
+  };
+
+  void ForwardGestureEvent(const blink::WebGestureEvent& gesture);
+  void CancelTapIfNecessary();
+  void CancelFlingIfNecessary();
+  TouchToGestureSequence& Head();
+  TouchToGestureSequence& Tail();
+
+  TouchToGestureQueueClient* client_;
+  std::deque<TouchToGestureSequence> sequences_;
+  bool handling_touch_event_;
+  bool outstanding_tap_;
+  bool outstanding_fling_;
+
+  DISALLOW_COPY_AND_ASSIGN(TouchToGestureQueue);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_RENDERER_HOST_INPUT_TOUCH_TO_GESTURE_QUEUE_H_