This would give us a sense of how many historical events we'd expect if we implemented such api.

Yes this would be useful. 

I was trying to think of a way to measure performance improvement (e.g. average processing time per raw event), but is it true that we always spend the same amount of time processing 1 event?

e.g.
Assuming in average we have X raw events in 1 coalesced event, so the performance improvement would just be roughly (X-1) times faster?

It's a bit scary to view this as a direct performance improvement, because if we did that, processing events once per second would be viewed as a massive win.

Roughly X times faster in your example, right? Not (X-1)?

I think we spend approximately the same amount of time per event for continuous events such as scroll and pinch.

For measuring the performance impact of vsync aligned compositor gestures, it's likely that compositor folks (enne/danakj) would have some thoughts.

Assigning to chongz. We might want to land this before turning vsync aligned input on 100%. We also might want it before rAF aligned input though.

The attachment is an example of tracing for queued events, where each entry of |CompositorThreadEventQueue::Queue| is a coalesced event in queue, with it's |type| and |coalesced_count| recorded.

Deleted: compositor_queue_tracing.png 149 KB

	compositor_queue_tracing.png 149 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6e0dbdfb8e8aec9b3066ce3e835e21e4915be4a

commit b6e0dbdfb8e8aec9b3066ce3e835e21e4915be4a
Author: chongz <chongz@chromium.org>
Date: Thu Feb 16 20:45:33 2017

[VSync Queue] Add tracing for event queuing time and coalesced count

We need these tracing to understand when the events are push and
popped, and how many events are coalesced together.

The tracing works as follow:
  1. For each new event, we first check if it could be coalesced with
    existing events or have to be pushed to the end
  2. If it could be coalesced, we simply coalesced it
  3. Otherwise we push and begin a new tracing with
    |id == new_event->first_original_event()|
  4. Each time an queue was popped we end the tracing with
    |id == new_event->first_original_event()|

Example flow of original events:

Case 1 - |ScrollUpdate| + |ScrollUpdate| => |ScrollUpdate|
Original Events - [o1, o2] + [o3, o4] => [o1, o2, o3, o4]

Case 2 - |PinchUpdate| + |ScrollUpdate| =>
             |ScrollUpdate| + |PinchUpdate|
Original Events - [o1, o2] + [o3, o4] =>
             [] + [o1, o2, o3, o4]

Please see bug for an example tracing picture.

BUG= 636332 

Review-Url: https://codereview.chromium.org/2695603004
Cr-Commit-Position: refs/heads/master@{#451094}

[modify] https://crrev.com/b6e0dbdfb8e8aec9b3066ce3e835e21e4915be4a/ui/events/blink/compositor_thread_event_queue.cc
[modify] https://crrev.com/b6e0dbdfb8e8aec9b3066ce3e835e21e4915be4a/ui/events/blink/event_with_callback.h
[modify] https://crrev.com/b6e0dbdfb8e8aec9b3066ce3e835e21e4915be4a/ui/events/blink/input_handler_proxy_unittest.cc

UMA was already added in https://crrev.com/2429953002