brianderson@, what's the best way to give Chrome OS the ability to use a custom VSYNC offsets per device for begin frame scheduling? Passing a different command line flag per device is common practice for Chrome OS so setting the offset that way would work for us.

Note that Arc++ is doing better than Chrome contents today as it doesn't use Chrome's begin frame callbacks but instead just an offset relative to HW vsync.

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

commit 41769318b72c3ca03f8da51ada352ac998672ee8
Author: dcastagna <dcastagna@chromium.org>
Date: Mon Mar 27 17:16:47 2017

cc: Fix DisplayScheduler:pending_swaps tracing.

Similar to AsyncSwapBuffer tracing, DisplayScheduler:pending_swaps tracing
was assuming at most one pending buffer would be in flight.
This was creating a misleading trace.

This CL removes that assumption, similar to what we did in
crrev.com/2770113003 for AsyncSwapBuffer.

BUG=705196
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/41769318b72c3ca03f8da51ada352ac998672ee8/cc/surfaces/display_scheduler.cc
[modify] https://crrev.com/41769318b72c3ca03f8da51ada352ac998672ee8/cc/surfaces/display_scheduler.h

@reveman: By produce a new frame, are you including Renderer work? Or are you only talking about cc::Display::Draw?

For CromeOS, would it be possible to retrieve the timestamp of when the GPU work for cc::Display::Draw completes relative it's CPU start time? Then do something dynamic based on that, which would take into account variance in both device and content. This is what I'm hoping to do for Android eventually.

If we go the hard coded route, we'll want to add an offset to the timebase just before DelayBasedBeginFrameSource::OnUpdateVSyncParameters is called:

https://cs.chromium.org/chromium/src/cc/scheduler/begin_frame_source.cc?l=144&gs=cpp%253Acc%253A%253Aclass-DelayBasedBeginFrameSource%253A%253AOnUpdateVSyncParameters(base%253A%253ATimeTicks%252C%2Bbase%253A%253ATimeDelta)%2540chromium%252F..%252F..%252Fcc%252Fscheduler%252Fbegin_frame_source.cc%257Cdef&gsn=OnUpdateVSyncParameters

Not sure which one applies to ChromeOS.

I'm not including work done by the Renderer. This is basically assuming the cost of Renderer is 0. The test case is a simple wayland client driven by begin frame callbacks. In my case the client prepares the frames in advance using sw raster and the delay between begin frame callback firing and the client producing a new frame is less than 0.1ms. I used this as a test to see what's the best possible BeginFrame + cc::Display::Draw scheduling on this device.

Timestamp of when the GPU work for cc::Display::Draw completes is not currently available. We get a timestamp for when the page flip happened, which is up to 16ms after that. Explicit sync will provide these type of timestamps in the future or we could get some less precise timestamps today using EGL sync objects that current time after waiting for the fence to complete on waiter thread.

Thanks for the OnUpdateVSyncParameters hint. I'll give that a try.

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

commit 0bebf0ea569d282c3db14f067b5e8fdebf023c34
Author: dcastagna <dcastagna@chromium.org>
Date: Mon Mar 27 22:14:28 2017

gpu: Fix AsyncSwapBuffer tracing.

AsyncSwapBuffer tracing assumed that at most one swap-buffer was in flight.
This is not true, since on CrOS we triple buffer and we can have up two
async swap-buffers pending.

The result of this was a confusing trace where one AsyncSwapBuffer trace
would start with swap-buffer timestamp of frame N and end at FinishSwapBuffer
timestamp of frame N - 1.

This CL fixes this issue using an id for every AsyncSwapBuffer trace.
In this way multiple (at most 2 hopefully) AsyncSwapBuffers can be visualised
at the same time in the tracing timeline.

BUG=705196
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/0bebf0ea569d282c3db14f067b5e8fdebf023c34/gpu/command_buffer/service/gles2_cmd_decoder.cc