cc: Add OutputSurface state snapshots.

cc: Add OutputSurface state snapshots.

This makes the surfaceless output surface used on ChromeOS produce
state snapshots that can be used for display latency measurements
when cc.debug.outputsurface category is enabled.

BUG=661010
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

[reveman, 2016-11-01 00:46:04]

Description was changed from

==========
content: Add cc::OutputSurface state snapshots.

This makes the surfaceless output surface used on ChromeOS produce
state snapshots that can be used for display latency measurements
when cc.debug.outputsurface category is enabled.

BUG=661010
==========

to

==========
content: Add cc::OutputSurface state snapshots.

This makes the surfaceless output surface used on ChromeOS produce
state snapshots that can be used for display latency measurements
when cc.debug.outputsurface category is enabled.

BUG=661010
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[reveman, 2016-11-01 22:43:23]

Description was changed from

==========
content: Add cc::OutputSurface state snapshots.

This makes the surfaceless output surface used on ChromeOS produce
state snapshots that can be used for display latency measurements
when cc.debug.outputsurface category is enabled.

BUG=661010
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Add OutputSurface state snapshots.

This makes the surfaceless output surface used on ChromeOS produce
state snapshots that can be used for display latency measurements
when cc.debug.outputsurface category is enabled.

BUG=661010
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[reveman, 2016-11-01 22:54:34]

reveman@chromium.org changed reviewers:
+ danakj@chromium.org

[reveman, 2016-11-01 22:54:34]

See
https://docs.google.com/a/google.com/document/d/1sj_RPGUlE_L3eVEJf7TeFYTVbFOf...
for more context.

Trace viewer side change can be found here:
https://codereview.chromium.org/2466023004

This is useful both for latency measurements and debugging the use of hw
overlays on ChromeOS.

[danakj, 2016-11-01 23:33:01]

I have a high level question. We show content inside frames already, why not
just highlight which layers were put into overlays and the content will come
from already existing sources? Showing this every 60 frames is going to make it
very unreliable for trying to debug stuff.

https://codereview.chromium.org/2465093002/diff/40001/cc/output/output_surfac...
File cc/output/output_surface_client.h (right):

https://codereview.chromium.org/2465093002/diff/40001/cc/output/output_surfac...
cc/output/output_surface_client.h:42: std::vector<SkBitmap>* bitmaps,
why not a parameter of the Callback?

https://codereview.chromium.org/2465093002/diff/40001/content/browser/composi...
File content/browser/compositor/browser_compositor_output_surface.cc (right):

https://codereview.chromium.org/2465093002/diff/40001/content/browser/composi...
content/browser/compositor/browser_compositor_output_surface.cc:64:
last_vsync_interval_ = interval;
shouldnt this be after the is_zero adjustment

[reveman, 2016-11-02 00:37:05]

On 2016/11/01 at 23:33:01, danakj wrote:
> I have a high level question. We show content inside frames already, why not
just highlight which layers were put into overlays and the content will come
from already existing sources? Showing this every 60 frames is going to make it
very unreliable for trying to debug stuff.

What do you mean by "inside frames"? If there's a better place to perform these
readbacks then we can move them as long as the following constraints are
fulfilled:

The main purpose of this patch is high accuracy latency measurements for Arc++
but it can also be used for debugging hw overlay support. Custom test
applications are expected to be used in both cases so it's easy to predict
output over a large number of frames. For latency measurements to be accurate
all work needed to capture these snapshots need to happen after the display
controller is done scanning out the buffer and it has been replaced by a new
buffer to avoid having the readback work effect the measurement. The interval
for the readback also needs to be large enough that one readback doesn't effect
the next readback. 60 frames has proven to be sufficient on the devices I've
tested this on so far.

Also, the buffers we receive from Arc++ are similar to the buffers in the buffer
queue and attempting to do a readback from the buffer directly without first
making a copy of the buffer using the GPU can be very slow.

https://codereview.chromium.org/2465093002/diff/40001/cc/output/output_surfac...
File cc/output/output_surface_client.h (right):

https://codereview.chromium.org/2465093002/diff/40001/cc/output/output_surfac...
cc/output/output_surface_client.h:42: std::vector<SkBitmap>* bitmaps,
On 2016/11/01 at 23:33:01, danakj wrote:
> why not a parameter of the Callback?

It just evolved this way. I guess the alternative is to pass
std::unique_ptr<std::vector<SkBitmap>> with this callback and
std::unique_ptr<SkBitmap> with the framebuffer version but it seemed a bit
easier to just allocate these objects upfront and the buffer queue and
outputsurface fill them in. Let me know if you prefer that or have a better idea
for how to do this.

https://codereview.chromium.org/2465093002/diff/40001/content/browser/composi...
File content/browser/compositor/browser_compositor_output_surface.cc (right):

https://codereview.chromium.org/2465093002/diff/40001/content/browser/composi...
content/browser/compositor/browser_compositor_output_surface.cc:64:
last_vsync_interval_ = interval;
On 2016/11/01 at 23:33:01, danakj wrote:
> shouldnt this be after the is_zero adjustment

Done.