Add hooks for flushing input from BeginFrame dispatch on Aura

Add hooks for flushing input from BeginFrame dispatch on Aura

When kEnableBeginFrameScheduling is enabled, allow flushing of input
from the InputRouter via the BeginFrame signal. Also allow the
InputRouter to request flushes directly.

BUG=394562

[jdduke (slow), 2015-10-16 20:09:28]

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

[jdduke (slow), 2015-10-16 20:09:29]

Brian, you mentioned unified BeginFrame will look a lot different in the near
future? Will this plumbing be pointless then? I'm trying to wire up a simple
patch that will let us tick the InputRouter to dispatch wheel/scroll events,
which will be a follow-up to this patch (see
https://chromiumcodereview.appspot.com/1405613002/).

[jdduke (slow), 2015-10-22 20:56:32]

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

[jdduke (slow), 2015-10-22 20:56:32]

+tdresser for content/browser/renderer_host/input

The key change here is that the InputRouter can request a flush, and RWHVAura
can perform that flush using the BeginFrame signal.

[brianderson, 2015-10-22 21:22:45]

+mithro, sunnyps

[brianderson, 2015-10-22 22:16:59]

On 2015/10/16 20:09:29, jdduke wrote:
> Brian, you mentioned unified BeginFrame will look a lot different in the near
> future? Will this plumbing be pointless then? I'm trying to wire up a simple
> patch that will let us tick the InputRouter to dispatch wheel/scroll events,
> which will be a follow-up to this patch (see
>
https://chromiumcodereview.appspot.com/1405613002/?_ga=1.66575019.421003098.1...).

I think most of this patch wont have to change when we transition over to the
new code path. mithro@ will just need to make sure to port over the
SetNeedsOneBeginFrame logic you've added here.

[danakj, 2015-10-22 22:42:03]

Oh cool, I'm going to add something like SetNeedsOneBeginFrame to the scheduler
for animations, I'll reuse that name. :)

[tdresser, 2015-10-23 12:32:07]

Compile failure appears real.

content/browser/renderer_host/input LGTM with minor nits, though if fixing the
compile requires major changes, I'd like to take another look.

https://codereview.chromium.org/1408213002/diff/40001/content/browser/rendere...
File content/browser/renderer_host/input/input_router_impl.h (right):

https://codereview.chromium.org/1408213002/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/input_router_impl.h:12: #include
"base/memory/scoped_vector.h"
Is this used?

https://codereview.chromium.org/1408213002/diff/40001/content/browser/rendere...
content/browser/renderer_host/input/input_router_impl.h:241: //
|DidFlushAllInput()| call to the client.
This leaves the case where we haven't received a |FlushInput()| call at all
ambiguous.

Can we reword to something like, 

Whether we've received a |FlushInput()| call without yet calling
|DidFlashAllInput()| on the client.

[jdduke (slow), 2015-10-23 15:10:55]

On 2015/10/23 12:32:07, tdresser (OOO Oct 26 - 29) wrote:
> Compile failure appears real.

Looks like the failure was from not changing RWHVA to use the new signature for
FlushInput, trivial fix there.

[jdduke (slow), 2015-10-23 18:00:39]

Test failures in latest patchset are fixed by the BeginFrame subscriber fix that
landed yesterday (crrev.com/1414533003).

https://chromiumcodereview.appspot.com/1408213002/diff/40001/content/browser/...
File content/browser/renderer_host/input/input_router_impl.h (right):

https://chromiumcodereview.appspot.com/1408213002/diff/40001/content/browser/...
content/browser/renderer_host/input/input_router_impl.h:12: #include
"base/memory/scoped_vector.h"
On 2015/10/23 12:32:07, tdresser (OOO Oct 26 - 29) wrote:
> Is this used?

Woops, bad rebase here I think... Removed.

https://chromiumcodereview.appspot.com/1408213002/diff/40001/content/browser/...
content/browser/renderer_host/input/input_router_impl.h:241: //
|DidFlushAllInput()| call to the client.
On 2015/10/23 12:32:07, tdresser (OOO Oct 26 - 29) wrote:
> This leaves the case where we haven't received a |FlushInput()| call at all
> ambiguous.
> 
> Can we reword to something like, 
> 
> Whether we've received a |FlushInput()| call without yet calling
> |DidFlashAllInput()| on the client.

Done.

https://chromiumcodereview.appspot.com/1408213002/diff/40001/content/browser/...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://chromiumcodereview.appspot.com/1408213002/diff/40001/content/browser/...
content/browser/renderer_host/render_widget_host_view_aura.cc:755:
host_->FlushInput(args.frame_time);
In theory, we might want to be more refined about our dispatch here, discerning
between the cases where an input flush was requested and the renderer signaled a
need for BeginFrames. However, for V1 I think this is fine, eventually it'd be
nice if Aura/Android(/Mac?) used a similar subscription model.

[danakj, 2015-11-02 21:54:20]

Are you going to be taking over this CL tim?

[jdduke (slow), 2015-11-02 21:56:25]

On 2015/11/02 21:54:20, danakj wrote:
> Are you going to be taking over this CL tim?

I'm happy to land it, was waiting for more feedback from Brian.

Brian any thoughts here? Should we just go ahead and land? Would you prefer we
introduce another flag to (semi)decouple the unified BeginFrame and
BeginFrame-aligined input logic?

[tdresser, 2016-11-28 15:27:35]

Description was changed from

==========
Add hooks for flushing input from BeginFrame dispatch on Aura

When kEnableBeginFrameScheduling is enabled, allow flushing of input
from the InputRouter via the BeginFrame signal. Also allow the
InputRouter to request flushes directly.

BUG=394562
==========

to

==========
Add hooks for flushing input from BeginFrame dispatch on Aura

When kEnableBeginFrameScheduling is enabled, allow flushing of input
from the InputRouter via the BeginFrame signal. Also allow the
InputRouter to request flushes directly.

BUG=394562
==========