Use input events to improve vsync scheduling

On some platforms like Android input events are buffered and delivered
right before the vsync notification signifying the start of a new frame.
We can use this information to improve vsync render scheduling in two
ways:
    
1) Normally subscribing to a vsync notification incurs one frame of lag,
  because the first event is only delivered for the next frame instead
  of the current one. Instead, we can use an input event to synthesize
  a virtual vsync event and start rendering the new frame immediately.

2) Input events and vsync notifications are sent as separate IPC
   messages. Since input events arrive first, we can increase the time
   available for rendering by using them instead of waiting for the
   vsync notification. The difference is about 1 ms on a Nexus 4.

This patch also avoids setting the "last input event before vsync" bit
on pages that have JavaScript touch handlers. This is because on such
pages touch events may be sent after the vsync notification depending on
what the JavaScript touch handler does with the events.
    
BUG=168459
TEST=VSyncTimeSourceTest.SynthesizeVSyncFromInput

[Sami, 2013-01-14 17:19:34]

This patch gets rid of the one frame lag when requesting a vsync notification
from the browser by synthesizing vsync events from input events. PTAL, thanks.

Depends on https://codereview.chromium.org/11833009/.

[brianderson, 2013-01-15 02:29:38]

Should VSyncTimeSourceTest.SynthesizeVSyncFromInput verify that input after a
vsync also triggers a tick?

Otherwise, lgtm.

[Sami, 2013-01-15 11:19:02]

> Should VSyncTimeSourceTest.SynthesizeVSyncFromInput verify that input after a
> vsync also triggers a tick?

Great idea, added. This version also removes the vsync bit from TouchMove
because otherwise on pages with touch handlers we'd get sent two input events
with the vsync flag set during a single frame.

[jamesr, 2013-01-16 04:13:26]

https://codereview.chromium.org/11854013/diff/13001/cc/vsync_time_source.cc
File cc/vsync_time_source.cc (right):

https://codereview.chromium.org/11854013/diff/13001/cc/vsync_time_source.cc#n...
cc/vsync_time_source.cc:58: // We can use input events to synthesize vsync
events, but we must be careful
this logic seems really fishy to me.  I think you need to decide if the smarts
for vsync are going to be in the renderer or not and stick to that - we
shouldn't have one process second-guessing the other

https://codereview.chromium.org/11854013/diff/13001/cc/vsync_time_source.cc#n...
cc/vsync_time_source.cc:68: return;
we should trace this early-out

https://codereview.chromium.org/11854013/diff/13001/content/browser/android/c...
File content/browser/android/content_view_core_impl.cc (left):

https://codereview.chromium.org/11854013/diff/13001/content/browser/android/c...
content/browser/android/content_view_core_impl.cc:873: event->type ==
WebInputEvent::TouchMove)
whaaaa? why was this here?

actually, this whole function seems kind of like bullshit.  we don't have any
way to tell that we're in this mode from the android framework?

[Sami, 2013-01-16 10:49:15]

https://codereview.chromium.org/11854013/diff/13001/cc/vsync_time_source.cc
File cc/vsync_time_source.cc (right):

https://codereview.chromium.org/11854013/diff/13001/cc/vsync_time_source.cc#n...
cc/vsync_time_source.cc:58: // We can use input events to synthesize vsync
events, but we must be careful
On 2013/01/16 04:13:26, jamesr wrote:
> this logic seems really fishy to me.  I think you need to decide if the smarts
> for vsync are going to be in the renderer or not and stick to that - we
> shouldn't have one process second-guessing the other

I suppose you're right. Doing this in the browser seems better because it has
global visibility across all renderers and all the funky input event queuing
happens there anyway. I'll give this another go to move the logic there.

https://codereview.chromium.org/11854013/diff/13001/content/browser/android/c...
File content/browser/android/content_view_core_impl.cc (left):

https://codereview.chromium.org/11854013/diff/13001/content/browser/android/c...
content/browser/android/content_view_core_impl.cc:873: event->type ==
WebInputEvent::TouchMove)
On 2013/01/16 04:13:26, jamesr wrote:
> whaaaa? why was this here?
> 
> actually, this whole function seems kind of like bullshit.  we don't have any
> way to tell that we're in this mode from the android framework?

From Android's point of view input events are always delivered right before
vsync if we're on JB+, but the problem is that we have at least two different
event queues between the framework and the renderer which affect which events
get sent and when.

Here I'm limiting the vsync bit to those events that are guaranteed to be sent
at the right time -- it doesn't make sense to do it for, e.g., the touch handler
case because the real vsync signal will have reached the renderer by the time we
get an ack from JS.

Maybe it would help if I move this logic to where the events are generated in
Java?