Plumb LatencyInfo through aura.

Plumb LatencyInfo through aura.

This will allow the tracking of latency through the browser compositor.

BUG=155367
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204147

[piman, 2013-05-31 04:13:44]

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/image_transport_factory.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/image_transport_factory.cc:365: }
Since this is all the same as CompositorOutputSurface::SwapBuffers, it's
tempting to move it to cc::OutputSurface::SwapBuffers.

Is the holdout that WebGraphicsContext3D doesn't have a way to set the latency
info without unsafe casts?

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2518: int process_id =
(b->first.second >> 32) & 0xffffffff;
I can't say that I'm the biggest fan of this. I guess it works for now but
doesn't seem very scalable to other source of latency. Also, if/when we want to
catch latency at the source (message pump) in the UI layers, we'll need another
set of component ids, that may conflict with this.

Maybe for a later patch, but could we have instead something like a global
registry of things that want notification of the latency info once it flew
through all the system? They could plug in their component ids and avoid having
to encode routing information into it. WDYT?

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_view_aura.cc:1562:
frame->metadata.device_scale_factor);
Can we also add it here (Übercomp)?

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_view_aura.cc:1568:
frame->metadata.device_scale_factor);
And here (software mode)?

[jbauman, 2013-05-31 21:51:36]

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/image_transport_factory.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/image_transport_factory.cc:365: }
On 2013/05/31 04:13:44, piman wrote:
> Since this is all the same as CompositorOutputSurface::SwapBuffers, it's
> tempting to move it to cc::OutputSurface::SwapBuffers.
> 
> Is the holdout that WebGraphicsContext3D doesn't have a way to set the latency
> info without unsafe casts?

Yeah, the WebGraphicsContext3D has no notion of the LatencyInfo (being in Blink
and all that).

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:2518: int process_id =
(b->first.second >> 32) & 0xffffffff;
On 2013/05/31 04:13:44, piman wrote:
> I can't say that I'm the biggest fan of this. I guess it works for now but
> doesn't seem very scalable to other source of latency. Also, if/when we want
to
> catch latency at the source (message pump) in the UI layers, we'll need
another
> set of component ids, that may conflict with this.

That's what the LatencyComponentType is for - to prevent conflicts between
different id namespaces.
> 
> Maybe for a later patch, but could we have instead something like a global
> registry of things that want notification of the latency info once it flew
> through all the system? They could plug in their component ids and avoid
having
> to encode routing information into it. WDYT?

Yeah, possibly. At least for now I wanted to keep it simple, while there's only
one consumer of these IDs, but later I can imagine it would make sense to have a
global registry.

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/15842013/diff/2001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_view_aura.cc:1562:
frame->metadata.device_scale_factor);
On 2013/05/31 04:13:44, piman wrote:
> Can we also add it here (Übercomp)?

Ok, sure.

[piman, 2013-05-31 21:55:30]

lgtm

[jbauman, 2013-05-31 21:58:12]

Also, jschuh@, could you look at the IPC change?

[jschuh, 2013-06-04 20:42:42]

sorry, was out sick for a bit. ipc security lgtm. opaque timing metadata.

[commit-bot: I haz the power, 2013-06-04 21:01:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jbauman@chromium.org/15842013/11001

[commit-bot: I haz the power, 2013-06-04 23:22:27]

Retried try job too often on win_rel for step(s) chrome_frame_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-06-04 23:24:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jbauman@chromium.org/15842013/11001

[commit-bot: I haz the power, 2013-06-05 03:38:31]

Change committed as 204147