Hook up DidReceiveInputEvent to the blink scheduler

content/renderer/input/input_handler_manager.h

Index: content/renderer/input/input_handler_manager.h
diff --git a/content/renderer/input/input_handler_manager.h b/content/renderer/input/input_handler_manager.h
index b6c70700526b9e7a1f907c56a7856f5181316e2d..44553a53873fd7bd84f5b7e2cf76ab1f105bef7e 100644
--- a/content/renderer/input/input_handler_manager.h
+++ b/content/renderer/input/input_handler_manager.h
@@ -28,16 +28,20 @@ namespace content {
 class InputHandlerWrapper;
 class InputHandlerManagerClient;
 struct DidOverscrollParams;
+class RendererScheduler;
 
 // InputHandlerManager class manages InputHandlerProxy instances for
 // the WebViews in this renderer.
 class InputHandlerManager {
  public:
-  // |message_loop_proxy| is the MessageLoopProxy of the compositor thread. Both
-  // the underlying MessageLoop and supplied |client| must outlive this object.
+  // |message_loop_proxy| is the MessageLoopProxy of the compositor thread. The
+  // underlying MessageLoop and supplied |client| and the |renderer_scheduler|
+  // must outlive this object. The RendererScheduler needs to know when input
+  // events and fling animations occur, which is why it's passed in here.
   InputHandlerManager(
       const scoped_refptr<base::MessageLoopProxy>& message_loop_proxy,
-      InputHandlerManagerClient* client);
+      InputHandlerManagerClient* client,
+      RendererScheduler* renderer_scheduler);
   ~InputHandlerManager();
 
   // Callable from the main thread only.
@@ -60,6 +64,12 @@ class InputHandlerManager {
   // Called from the compositor's thread.
   void DidStopFlinging(int routing_id);
 
+  // Called from the compositor's thread.
+  void DidReceiveInputEvent();

[jdduke (slow), 2014/11/07 02:54:54]

If we plumb the event type through here
(DidReceiveInputEvent(blink::WebInputEvent::Type)), we can let the scheduler
make the right decision about how to respond. Per discussion in
crbug.com/429814, I'd prefer we start by restricting prioritization when we see
touch/gesture/wheel events, but not mouse/keyboard. We can always expand
coverage later.

[alex clarke (OOO till 29th), 2014/11/07 16:59:11]

This seems like a good idea, but it feels like it might be cleaner if done in a
separate patch. WDYT?

+
+  // Called from the compositor's thread.
+  void DidAnimateForInput();
+
  private:
   // Called from the compositor's thread.
   void AddInputHandlerOnCompositorThread(
@@ -74,6 +84,7 @@ class InputHandlerManager {
 
   scoped_refptr<base::MessageLoopProxy> message_loop_proxy_;
   InputHandlerManagerClient* client_;
+  RendererScheduler* renderer_scheduler_;  // Not owned.
 };
 
 }  // namespace content