Add latency measurement system

Add latency measurement system

This adds a new WebKit::WebLatencyInfoImpl struct, and sends it from the renderer, through the compositor, GPU process, and possibly aura, and then back to the renderer with the swap timestamp after the swap has occurred. We use sequence numbers in the struct to determine what input events caused a specific swap to happen.

BUG=155367

[jbauman, 2012-11-06 19:08:33]

The render_widget_host, render_widget, and impl thread each have separate
numbers that are sent to the next component in the chain upon input event
message or commit or swap or similar, and at the end the swapbuffers gets a
vector of the corresponding numbers and a timestamp, which it sends to the
renderwidgethostimpl.

I'm still trying to figure out what interface we should use for this. Currently
there's a callback that will be called on every swap, so you can match up the
input number and time from the callback with the input number and time when you
first sent an input event. This is a pain to use, but it can deal with the
renderer dropping frames because there's nothing to draw.

Also, there will probably be issues plumbing these separate numbers into aura,
as they're each RenderWidget-specific, so we can't (for example) take the max of
all of them globally.

[jbauman, 2012-11-19 21:00:46]

Ok, I added support for aura (based somewhat on ajuma's patch), added a
mechanism for sending the swap timestamp back all from the browser to the gpu
process to the browser to the gpu process to the renderer to the gpu process,
and combined all the various frame numbers and swap timestamps into one struct
that's passed around everywhere (that struct isn't in this patch, because it's
in WebKit, but it's pretty simple).

[jamesr, 2012-11-19 21:39:27]

Are you worried about overflow on the input numbering?  I think a safe upper
bound on input rate would be something like 1000hz (imagine some gamer cranking
up his USB poll rate or something - but also remember that a single user
interaction like pushing a key down can result in several input events), but
that would overflow in 24 days if my math is right.  Seems to be on the edge
where we could imagine a user overflowing without stretching the imagination too
much.

[jbauman, 2012-11-19 21:45:28]

On 2012/11/19 21:39:27, jamesr wrote:
> Are you worried about overflow on the input numbering?  I think a safe upper
> bound on input rate would be something like 1000hz (imagine some gamer
cranking
> up his USB poll rate or something - but also remember that a single user
> interaction like pushing a key down can result in several input events), but
> that would overflow in 24 days if my math is right.  Seems to be on the edge
> where we could imagine a user overflowing without stretching the imagination
too
> much.

I'm not too worried about this overflowing, as people probably won't be running
latency tests or whatever on 24-day-old chrome instances. However, it wouldn't
be hard to modify it to use 64-bit counters, so I could do that.

[jbauman, 2012-12-12 22:34:35]

Ok, this is probably ready for review now.

[jamesr, 2013-01-02 23:23:39]

I think this needs some deps massaging to get into a landable state. Is there an
overview somewhere of what all the data is and how it's flowing around between
processes/threads/systems?

https://codereview.chromium.org/11293121/diff/46001/cc/DEPS
File cc/DEPS (right):

https://codereview.chromium.org/11293121/diff/46001/cc/DEPS#newcode14
cc/DEPS:14: "+webkit/compositor_bindings/web_latency_info_impl.h",
this is not good - cc/ shouldn't depend on the webkit bindings - the bindings
already depend on cc so that would create a cycle.  You could declare a struct
in cc/ that had the latency information and then have a wrapper or adapter in
webkit/compositor_bindings/ to let WebKit access the same data

https://codereview.chromium.org/11293121/diff/46001/cc/gl_renderer.h
File cc/gl_renderer.h (right):

https://codereview.chromium.org/11293121/diff/46001/cc/gl_renderer.h#newcode40
cc/gl_renderer.h:40: public
NON_EXPORTED_BASE(WebKit::WebGraphicsContext3D::WebGraphicsLatencyInfoCallbackCHROMIUM){
Why do these come back through a WebGraphicsContext3D interface?  They don't
really have anything to do with a context unless it's a view context, and in
that case they seem more logically part of the surface.

[jbauman, 2013-01-03 01:30:39]

On 2013/01/02 23:23:39, jamesr wrote:
> I think this needs some deps massaging to get into a landable state. Is there
an
> overview somewhere of what all the data is and how it's flowing around between
> processes/threads/systems?

Not really. Generally there's just one struct (the WebLatencyInfoImpl in the
patch, though I just renamed it to the cc::LatencyInfo) that's passed along from
the renderer main thread through the compositor through the gpu process, etc.
until the swap buffers happens. There it gets the swap timestamp, and is passed
back in reverse until it hits the renderer. The precise details depend on what
platform it's on and whether aura is being used.

As the struct is passed back up the chain any component can see, based on the
frame numbers and input number, what events were captured in this frame and
therefore what the latency for each of those events was.
> 
> https://codereview.chromium.org/11293121/diff/46001/cc/DEPS
> File cc/DEPS (right):
> 
> https://codereview.chromium.org/11293121/diff/46001/cc/DEPS#newcode14
> cc/DEPS:14: "+webkit/compositor_bindings/web_latency_info_impl.h",
> this is not good - cc/ shouldn't depend on the webkit bindings - the bindings
> already depend on cc so that would create a cycle.  You could declare a struct
> in cc/ that had the latency information and then have a wrapper or adapter in
> webkit/compositor_bindings/ to let WebKit access the same data
> 
> https://codereview.chromium.org/11293121/diff/46001/cc/gl_renderer.h
> File cc/gl_renderer.h (right):
> 
> https://codereview.chromium.org/11293121/diff/46001/cc/gl_renderer.h#newcode40
> cc/gl_renderer.h:40: public
>
NON_EXPORTED_BASE(WebKit::WebGraphicsContext3D::WebGraphicsLatencyInfoCallbackCHROMIUM){
> Why do these come back through a WebGraphicsContext3D interface?  They don't
> really have anything to do with a context unless it's a view context, and in
> that case they seem more logically part of the surface.

[jbauman, 2013-01-03 03:57:25]

Thanks for the review. I've uploaded a new version which hopefully addresses
those issues.

[nduca, 2013-01-03 20:17:11]

I think a design doc would help for this. @jbauman, can you and ali do a design
doc on "latency measurement in chrome" and send it to jamesr and I? When its
good ,we can send it around to chrome-gpu and once its good, I think it'll help
drive this review forward.

[nduca, 2013-03-13 05:10:53]

@jbauman, with impl side craziness settling down, how can I help unblock this? I
know we stalled out largely because I stalled the review... :$