InputHandlerProxy to inform blink scheduler of input events

InputHandlerProxy to inform blink scheduler of input events

The blink scheduler needs to know when input events are received since
it uses that as a signal to prioritize compositor tasks
over other main thread tasks which reduces queueing durations and
input event latency.

BUG=391005, 411520
Committed: https://crrev.com/1ec1dbcc68ee3590b3b296617c5eaafb1e6de04b
Cr-Commit-Position: refs/heads/master@{#294573}

[Sami, 2014-09-10 16:41:22]

skyostil@chromium.org changed reviewers:
+ skyostil@chromium.org

[Sami, 2014-09-10 16:41:23]

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
content/renderer/input/input_handler_proxy.cc:189:
client_->DidHandleInputEvent();
DidReceiveInputEvent

No need for this call here.

[jdduke (slow), 2014-09-10 17:02:26]

jdduke@chromium.org changed reviewers:
+ jdduke@chromium.org

[jdduke (slow), 2014-09-10 17:02:27]

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
File content/renderer/input/input_handler_wrapper.cc (right):

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
content/renderer/input/input_handler_wrapper.cc:62:
web_scheduler_proxy_.didReceiveInputEvent();
What kind of work might this call trigger?

[Sami, 2014-09-10 17:23:00]

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
File content/renderer/input/input_handler_wrapper.cc (right):

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
content/renderer/input/input_handler_wrapper.cc:62:
web_scheduler_proxy_.didReceiveInputEvent();
On 2014/09/10 17:02:26, jdduke wrote:
> What kind of work might this call trigger?

It lets the scheduler know the time of the last incoming input event so we can
estimate if they user is interacting with the device or not. This notification
by itself won't cause any work other than grabbing a lock (or an atomic write),
looking at the current time and setting a flag.

[alexclarke, 2014-09-11 16:00:33]

alexclarke@google.com changed reviewers:
+ alexclarke@google.com

[alexclarke, 2014-09-11 16:00:33]

I think this is ready for review now.

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/1/content/renderer/input/input...
content/renderer/input/input_handler_proxy.cc:189:
client_->DidHandleInputEvent();
On 2014/09/10 16:41:23, Sami wrote:
> DidReceiveInputEvent
> 
> No need for this call here.

Done.

[jdduke (slow), 2014-09-11 16:29:35]

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
content/renderer/input/input_handler_proxy.cc:198:
client_->DidReceiveInputEvent();
This method is called internally for synthetic wheel/fling gestures, is it OK
that the client is notified in such cases? Or do we only want it when we receive
an external event? Honestly, this method should be private, but I think
somewhere along the line somebody thought it convenient to keep public for
testing purposes.

[Sami, 2014-09-11 16:42:31]

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
content/renderer/input/input_handler_proxy.cc:198:
client_->DidReceiveInputEvent();
On 2014/09/11 16:29:35, jdduke wrote:
> This method is called internally for synthetic wheel/fling gestures, is it OK
> that the client is notified in such cases? Or do we only want it when we
receive
> an external event? Honestly, this method should be private, but I think
> somewhere along the line somebody thought it convenient to keep public for
> testing purposes.

I think we want to have it called for flings too, since they were still
initiated by the user and count as interacting with the device in my mind.

[Sami, 2014-09-11 16:44:10]

My magic has no power here, but lgtm.

[alexclarke, 2014-09-11 16:45:00]

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
content/renderer/input/input_handler_proxy.cc:198:
client_->DidReceiveInputEvent();
On 2014/09/11 16:29:35, jdduke wrote:
> This method is called internally for synthetic wheel/fling gestures, is it OK
> that the client is notified in such cases? Or do we only want it when we
receive
> an external event? Honestly, this method should be private, but I think
> somewhere along the line somebody thought it convenient to keep public for
> testing purposes.

Yes I think we do want to treat synthetic events the same, since this should
make the user initiated animation smoother.

[jdduke (slow), 2014-09-11 16:49:11]

lgtm, thanks.

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
File content/renderer/input/input_handler_proxy.cc (right):

https://codereview.chromium.org/557403002/diff/20001/content/renderer/input/i...
content/renderer/input/input_handler_proxy.cc:198:
client_->DidReceiveInputEvent();
On 2014/09/11 16:45:00, alexclarke wrote:
> On 2014/09/11 16:29:35, jdduke wrote:
> > This method is called internally for synthetic wheel/fling gestures, is it
OK
> > that the client is notified in such cases? Or do we only want it when we
> receive
> > an external event? Honestly, this method should be private, but I think
> > somewhere along the line somebody thought it convenient to keep public for
> > testing purposes.
> 
> Yes I think we do want to treat synthetic events the same, since this should
> make the user initiated animation smoother.

sgtm.

[alexclarke, 2014-09-12 10:23:08]

The CQ bit was checked by alexclarke@google.com

[commit-bot: I haz the power, 2014-09-12 10:23:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/557403002/20001

[commit-bot: I haz the power, 2014-09-12 10:42:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-12 10:42:32]

Try jobs failed on following builders:
  linux_chromium_gn_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[alexclarke, 2014-09-12 10:58:21]

The CQ bit was checked by alexclarke@google.com

[commit-bot: I haz the power, 2014-09-12 10:58:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/557403002/20001

[commit-bot: I haz the power, 2014-09-12 11:24:19]

Committed patchset #2 (id:20001) as 37e699550cea8d57b7af54a484825ef9b8449764

[commit-bot: I haz the power, 2014-09-12 11:26:25]

Patchset 2 (id:??) landed as
https://crrev.com/1ec1dbcc68ee3590b3b296617c5eaafb1e6de04b
Cr-Commit-Position: refs/heads/master@{#294573}