GraphicsPipeline.Browser.ReceivedBeginFrame measures the difference between BeginFrameArgs::frame_time and when the client, either DirectLayerTreeFrameSink or AsyncLayerTreeFrameSink, receives the OnBeginFrame() message.

For platforms that use a DelayBasedBeginFrameSource (Windows and Linux) |frame_time| is set to when the DelayBasedTimeSource is set to tick next. If task for the timer runs late due to scheduling delay that delay would be part of GraphicsPipeline.Browser.ReceivedBeginFrame.

For non-OOP-D the timer runs on browser UI thread. Queuing delay on the UI thread would be included in GraphicsPipeline.Browser.ReceivedBeginFrame. There is a direct function call to DirectLayerTreeFrameSink::OnBeginFrame() so there is essentially zero delay after the timer runs.

For OOP-D the timer runs on the display compositor thread in the GPU process. Queuing delay on the display compositor thread would be added to GraphicsPipeline.Browser.ReceivedBeginFrame. Also OnBeginFrame() needs to get send over IPC from GPU to browser process. Queuing delay on the browser IO or UI threads would impact when the IPC is received in the browser and would also be included in GraphicsPipeline.Browser.ReceivedBeginFrame.

Looking at some traces from Windows, DelayBasedTimeSource schedules the next tick only after Display::DrawAndSwap() finishes. For non OOP-D if the browser UI thread has high queuing delay that will also impact when Display::DrawAndSwap() runs. This means that the next timer tick won't be scheduled until later AND that at most one outstanding OnBeginFrame() can be waiting in the browser.

With OOP-D the display compositor thread can continue to draw, even if the browser UI thread is bogged down, so the OnBeginFrame() will be generated earlier and the first GraphicsPipeline.Browser.ReceivedBeginFrame will be larger. Also the display compositor can continue to draw and many OnBeginFrame() can happen before the browser UI thread becomes responsive again.

At least part of the regression is in how we are measuring things. Even if the browser UI thread has high queuing delay the display compositor can continue to draw if there is a responsive client. There is an improvement in GraphicsPipeline.Renderer.ReceivedBeginFrame (except on Mac which needs more investigation) which would support this.

I'm wondering if there are also some big sources of queuing delay for the display compositor thread. I'll investigate if some InProcessCommandBuffer operations are slower than the equivalent operation on CommandBufferProxyImpl. For example, it looks like InProcessCommandBuffer::Initialize() might be slower than CommandBufferProxyImp::Initialize().

One source of queuing delay is anything that causes InProcessCommandBuffer
to wait e.g. running out of command buffer or transfer buffer space.  We
don't expect this to happen often for display compositor since it will be
prioritized by GPU scheduler, but long commands on the other contexts (ex.
raster) could cause this.

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

commit 73a7ca461b7538c8c178af601e9c587490daa26c
Author: kylechar <kylechar@chromium.org>
Date: Thu Sep 27 22:44:26 2018

Add trace events to InProcessCommandBuffer.

InProcessCommandBuffer is being used for the display compositor with
OOP-D. Add trace events for key functions, similar to the existing
traces in CommandBufferProxyImpl and [GLES2]CommandBufferStub, to help
diagnose performance issues.

Bug: 832243,  890013 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I34b962b48ad4eb10b112a9c979056993868637a4
Reviewed-on: https://chromium-review.googlesource.com/1250043
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: Jonathan Backer <backer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594902}
[modify] https://crrev.com/73a7ca461b7538c8c178af601e9c587490daa26c/gpu/ipc/in_process_command_buffer.cc

For non-OOP-D we'd see the same blocking behaviour on the browser UI thread if the ui::Compositor+Display command buffer filled up in the same way right?

Another thing that could be contributing here. With OOP-D all ui::Compositors share one ContextProvider and command buffer. With multiple top level windows open we might be filling up that command buffer more often causing the browser UI thread to wait. I don't think we keep track of how often this happens?