danakj: Request for comment.


Approach A:

1) Modify cc::TextureMailbox to have a generic cc::Waitable instead of a SyncToken. A cc::Waitable is a wrapper around a SyncToken, or a waitable-GpuMemoryBufferHandle. 
2) Plumb something equivalent through WebExternalTextureMailbox. [This requires teaching WebKit about Scoped Mach Ports, and the public API for IOSurfaces, or else allowing more includes from ui/.

Approach B:

1) Modify the command buffer SyncToken extension to support waiting on a GMBHandle. They main question is: Who owns the GMBHandle? SyncTokens are "unowned", and all the code that handles it doesn't bother with ownership semantics. I think we would have to add at least one new command buffer API to deal with this ownership semantics.

The benefit is that no additional plumbing is needed in WebKit.

Approach C:

1) Modify cc::TextureLayerImpl and cc::ResourceProvider to not return GMB-textures until they have been freed.

The benefit is that this requires no additional plumbing in WebKit. The downside is that this architecturally feels like the wrong place to be holding onto resources (and kind of defeats the purpose of passing around a SyncToken in cc::TextureMailbox).


I prefer Approach A. danakj, thoughts?

Hmm.. I think we need reveman/piman to weigh in here, I'm not too familiar with GpuMemoryBuffer<->CommandBuffer interaction. Also +dyen who wrote the new sync token stuff.

A1 feels a little indirection-heavy. But it does encapsulate the fact that it's bound to an IO surface well. The goal of TextureMailbox is to make something that's as equivalent as possible for GPU and Software. I guess that is extended to native GMBs now too.

A2 OTOH forces the client to know resource are IO-surface backed. How much of that does the client already know, given that it is generating the TextureMailbox in the first place? What things does it not know now that it'd have to be exposed to?

B I have trouble commenting on, I am not familiar with GMBHandle ownership, so I have trouble verifying if we would/n't need to deal with it.

C doesn't see contradictory to me. cc::ResourceProvider holds ownership of resources until it hears that they are no longer in use. Normally that message comes with a SyncToken for the client to wait on. In this case it wouldn't I guess, it would instead com from the window server. It does introduce additional latency (thread hop from cc to main thread) after the window server message state is read I guess.

Oh, if you're happy with (C), I'm happy to short-circuit this discussion and just implement it, since it's contained within cc/ and you're an OWNER. I'll wait a bit just to let everyone else weigh in, I guess.

I'm not sure if that latency in C is going to be a problem, it's not ideal at least. How do we check GpuMemoryBufferImplIOSurface::IsInUseByMacOSWindowServer()? Can it be on any thread? Is it on the GPU process? Do we poll or how do we hear?

Also can you answer my questions about A2?

A2: The client generates a gpu::Mailbox via command buffer APIs, and knows that it is associated with a texture. Beyond that, it doesn't know any of the implementation details [GMBs, GLImage, etc. are all implementation details of the command buffer].

GpuMemoryBufferImplIOSurface::IsInUseByMacOSWindowServer() is a wrapper around IOSurfaceIsInUse(). This can be called from any process and thread that has access to the IOSurface API, and a reference to a valid IOSurface.

ccameron@ is in the process of plumbing GMBHandles through cc and TextureMailbox mostly to support CA Compositor changes, although partly for this as well.
https://codereview.chromium.org/1930193002/

I believe C is the way to go here. It's the more principled way of implementing what we already have in cc::GLRenderer::pending_overlay_resources_.

WRT A: I don't like the idea of "waiting" on the GMB to be freed in the GL process. It isn't really a "wait"-able thing (poll-able, sort of). It also isn't something that is guaranteed to arrive at any point, so doing a client-side wait on it will probably hang in unexpected times and places.

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

commit 64d59f650c4f3a957f28943858fbb6b60754b98b
Author: erikchen <erikchen@chromium.org>
Date: Mon May 02 20:17:45 2016

Turn off IOSurface implementation for Canvas2D.

IOSurface texures can't be reused because the compositor returns them while they
are still in use by the Window Server, and the SyncToken isn't relevant.

BUG= 608026 

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

[modify] https://crrev.com/64d59f650c4f3a957f28943858fbb6b60754b98b/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h

Ok, I don't like A2 if the client isn't make decisions about IO surfaces or not.

A1 seems like a deferred version of C, where we basically move that logic to the client but hide it behind something ResourceProvider knows how to make. So I guess you could say it's a performance optimization of C to remove the latency to get to the cc client, after the IO surface is released.

OTOH B has nice symmetry that the fact it's IO surface-bound is hidden behind the command buffer right now, but maybe that's insufficient.

I think I'm okay with C and Chris suggesting that makes me more confident :) And we can look at A1 if we want to optimize it.

How do we do this on Ozone? We have the same issue there.

+alexst if you remember how that is done

Ozone holds a read lock until the next swap in the browser's cc::GLRenderer::pending_overlay_resources_.

Mac does something very similar except it waits until the swap-ack to release the read-lock.

This merges very well with C, where, when each swap comes in, we release all read-locks from the previous frame that are on IOSurfaces that are no longer in use.

FYI, I'm in the process of adding Android explicit sync primitives to Chromium and using them for GMB synchronization: https://chromium.googlesource.com/chromium/src/+/8d6342181e81b6dd0988283b785d0724c686f096

ChromeOS is going to start using this for GMB synchronization asap. My current plan is to wrap this in a platform independent gfx::SharedWaitableEvent and implement a simple shared mutex version for platforms without Android explicit sync support. Something like this:

#if defined(OS_CHROMEOS) || defined(OS_ANDROID)
typedef FileDescriptor SharedWaitableEventHandle;
#endif

class SharedWaitableEvent {
 public:
  void Signal();
  bool IsSignaled();
  void Wait();
  bool TimedWait(const TimeDelta& max_time);
  SharedWaitableEventHandle GetHandle();
}

This is exactly what we want for native GMBs on Android and ChromeOS but also happens to work really well for our shmem fallback GMBs. Not sure how well this fits the IOSurface use-case but it would be awesome if we could use it there too. ccameron@, wdyt?

I think that controlling this by delaying the return of resources from the browser process to the renderer process is the way to go for IOSurfaces. We will always have a concept of returning resources, and this just folds the WindowServer's use into the browser process (or the "main compositor process").

In retrospect, we should have made the GPU process do this (we still could, but I'm trying to kill off the roles that it has).

I don't think that the IOSurface InUse concept works well with a "wait" type API. We don't get any signal when the IOSurface's InUse count drops to zero, so we'd need to poll it. We can't reason very well about when or if the InUse will drop, so we're likely to deadlock.

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

commit fce5bedb610e4bd9cc40f67d9d91078ece7089b1
Author: erikchen <erikchen@chromium.org>
Date: Fri May 06 22:57:56 2016

[Merge to 2704] Turn off IOSurface implementation for Canvas2D.

IOSurface texures can't be reused because the compositor returns them while they
are still in use by the Window Server, and the SyncToken isn't relevant.

BUG= 608026 

Review-Url: https://codereview.chromium.org/1932393002
Cr-Commit-Position: refs/heads/master@{#391043}
(cherry picked from commit 64d59f650c4f3a957f28943858fbb6b60754b98b)

Review URL: https://codereview.chromium.org/1953293005 .

Cr-Commit-Position: refs/branch-heads/2704@{#435}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/fce5bedb610e4bd9cc40f67d9d91078ece7089b1/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h

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

commit 87aa976eacd8ed0c530d32a7c85d6ba706dcabf6
Author: erikchen <erikchen@chromium.org>
Date: Fri May 20 20:13:48 2016

Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources.

The new logic will hold onto GpuMemoryBuffer Resources until they are no longer
in use by the Window Server.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6/cc/output/gl_renderer.cc
[modify] https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6/cc/output/gl_renderer.h
[modify] https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6/cc/resources/resource_provider.cc
[modify] https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6/cc/resources/resource_provider.h

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

commit aa5126ff66379a9060e87b010135f1aee7fc1ab2
Author: erikchen <erikchen@chromium.org>
Date: Tue May 24 02:59:49 2016

Revert of Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources. (patchset #8 id:140001 of https://codereview.chromium.org/1984873002/ )

Reason for revert:
Depending on an implementation still in review. Results in flooding of LOG messages.

https://bugs.chromium.org/p/chromium/issues/detail?id=614155
https://codereview.chromium.org/1993333002/

Original issue's description:
> Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources.
>
> The new logic will hold onto GpuMemoryBuffer Resources until they are no longer
> in use by the Window Server.
>
> BUG= 608026 
> CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6
> Cr-Commit-Position: refs/heads/master@{#395150}

TBR=ccameron@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 608026 

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

[modify] https://crrev.com/aa5126ff66379a9060e87b010135f1aee7fc1ab2/cc/output/gl_renderer.cc
[modify] https://crrev.com/aa5126ff66379a9060e87b010135f1aee7fc1ab2/cc/output/gl_renderer.h
[modify] https://crrev.com/aa5126ff66379a9060e87b010135f1aee7fc1ab2/cc/resources/resource_provider.cc
[modify] https://crrev.com/aa5126ff66379a9060e87b010135f1aee7fc1ab2/cc/resources/resource_provider.h

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

commit f8a942fbb35c30edcc88cfe859ceda7b469096af
Author: ccameron <ccameron@chromium.org>
Date: Thu May 26 18:24:10 2016

Reland of Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources. (patchset #1 id:1 of https://codereview.chromium.org/2006153002/ )

Reason for revert:
The patch that this depended on, https://codereview.chromium.org/1993333002/, has landed.

Original issue's description:
> Revert of Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources. (patchset #8 id:140001 of https://codereview.chromium.org/1984873002/ )
>
> Reason for revert:
> Depending on an implementation still in review. Results in flooding of LOG messages.
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=614155
> https://codereview.chromium.org/1993333002/
>
> Original issue's description:
> > Add logic to ResourceProvider to correctly lock GpuMemoryBuffer Resources.
> >
> > The new logic will hold onto GpuMemoryBuffer Resources until they are no longer
> > in use by the Window Server.
> >
> > BUG= 608026 
> > CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
> >
> > Committed: https://crrev.com/87aa976eacd8ed0c530d32a7c85d6ba706dcabf6
> > Cr-Commit-Position: refs/heads/master@{#395150}
>
> TBR=ccameron@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG= 608026 
>
> Committed: https://crrev.com/aa5126ff66379a9060e87b010135f1aee7fc1ab2
> Cr-Commit-Position: refs/heads/master@{#395524}

TBR=erikchen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 608026 

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

[modify] https://crrev.com/f8a942fbb35c30edcc88cfe859ceda7b469096af/cc/output/gl_renderer.cc
[modify] https://crrev.com/f8a942fbb35c30edcc88cfe859ceda7b469096af/cc/output/gl_renderer.h
[modify] https://crrev.com/f8a942fbb35c30edcc88cfe859ceda7b469096af/cc/resources/resource_provider.cc
[modify] https://crrev.com/f8a942fbb35c30edcc88cfe859ceda7b469096af/cc/resources/resource_provider.h

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

commit cc0c4c335e8662ed709dbc69726dbbc37e1c3368
Author: ccameron <ccameron@chromium.org>
Date: Thu May 26 20:51:50 2016

cc: Remove InUseByMacOSWindowServer

The parent compositor's ResourceProvider will not return resources
to the child compositor when they are still in use by the window
server, making this code redundant.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/cc/resources/resource_pool.cc
[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/cc/resources/resource_provider.cc
[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/cc/resources/resource_provider.h
[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/cc/resources/resource_provider_unittest.cc
[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/cc0c4c335e8662ed709dbc69726dbbc37e1c3368/media/video/gpu_memory_buffer_video_frame_pool_unittest.cc

Still requires some more WebKit plumbing.

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

commit 11c5d208606dbce8660ad7f5e41e0aa770655c82
Author: erikchen <erikchen@chromium.org>
Date: Fri May 27 18:04:22 2016

Expose GpuMemoryBufferId through glGetImageivCHROMIUM.

WebKit widgets that provide textures to TextureLayer need to also provide the
GpuMemoryBufferId if the texture is backed by a GpuMemoryBuffer. This CL
modifies the CHROMIUM Image extension to allow the GpuMemoryBuffer id to be
obtained by a new function glGetImageivCHROMIUM.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/cc/test/test_gles2_interface.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/cc/test/test_gles2_interface.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/cc/test/test_web_graphics_context_3d.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/cc/test/test_web_graphics_context_3d.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/components/mus/gles2/command_buffer_local.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/components/mus/gles2/command_buffer_local.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/components/mus/public/cpp/lib/command_buffer_client_impl.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/components/mus/public/cpp/lib/command_buffer_client_impl.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/GLES2/gl2chromium_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/GLES2/gl2extchromium.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/build_gles2_cmd_buffer.py
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/client_test_helper.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_c_lib_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_implementation.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_implementation_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_interface_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_interface_stub_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_trace_implementation_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gles2_trace_implementation_impl_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/client/gpu_control.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/cmd_buffer_functions.txt
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/service/in_process_command_buffer.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/service/in_process_command_buffer.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/tests/gl_manager.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/command_buffer/tests/gl_manager.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/gles2_conform_support/egl/context.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/gles2_conform_support/egl/context.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/ipc/client/command_buffer_proxy_impl.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/gpu/ipc/client/command_buffer_proxy_impl.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/ppapi/proxy/ppapi_command_buffer_proxy.cc
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/ppapi/proxy/ppapi_command_buffer_proxy.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/GraphicsTypes3D.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/11c5d208606dbce8660ad7f5e41e0aa770655c82/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferTest.cpp

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

commit a0f4b5051a2ef87f7de7cb469fe87d781cc0ab35
Author: erikchen <erikchen@chromium.org>
Date: Wed Jun 01 17:54:24 2016

Reenable IOSurfaces for Canvas on Mac.

The browser compositor now waits until IOSurfaces are no longer in use by the
Window Server before returning them.

BUG= 608026 

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

[modify] https://crrev.com/a0f4b5051a2ef87f7de7cb469fe87d781cc0ab35/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h

While this functionality technically works, it doesn't extend to pepper surfaces. Extending it to work with pepper surfaces is non trivial: https://docs.google.com/document/d/1rkWseZXdIaSh_qXRE4dmGbwmu08In_HxiLvMm-gpjFc/edit#heading=h.vhz6h2vo07qm

We discussed this further in an email thread, and it seems best to do the in-use check in the gpu process. Quoting the end of the thread:

"""
On Tue, Jun 7, 2016 at 11:19 AM, Christopher Cameron <ccameron@google.com> wrote:
WRT how to detect the "is in use". A suggestion:

Put this in this in GL_CHROMIUM_schedule_ca_layer

Add a function
glScheduleCALayerInUseQueryCHROMIUM(GLuint n, GLuint* textures);
which is called by GLRenderer

This makes its way down the ImageTransportSurfaceOverlayMac, which queries IOSurface properties.

Then have GpuCommandBufferMsg_SwapBuffersCompleted_Params return the vector of textures and "is in use" values.
"""

"""
Hey all, belated reply... 

First, thanks a lot Chris for the design doc - gives a lot of clarity into the direction.

My short-term view is that while it probably gets us into a better place on Mac, it has 2 downsides on top of the ones you listed in the document:
1- it makes the Mac code path diverge even more from the other platforms (hence increased maintenance/testing burden).
2- it makes it harder to promote Pepper to an overlay, which I think would have some perf/power benefits?

#2 is solvable, and #1 is probably easier to take on if other platforms benefit (e.g. Ozone/DRM? Windows + DirectComposition? Wayland?), but for that my temptation would be to experiment with those and make sure the API we design and the involved concepts would work for those.
At the same time, I think in the Mus world, a bunch of the involved problems disappear - if UI and GPU merge then we don't need to "choose" which process does what. If we can make sure Mus is designed with that in mind, we'll be in a better place overall long term.

So I guess, if we're willing to wait for the Mus world, it is appealing to keep it simple and get the immediate benefits from keeping things in the GPU process.


Specifically for the in-use bit, your suggested solution works for me. It has a bit of latency (next swap) - is the idea that you would query the in-use bit right after the layer commit and just before sending the ack IPC so that you have the most up-to-date values when you receive the message? I think the latency is ok based on the client-side usage. I also think it could also fit well with the Ozone/DRM version - do you think we can name it something that allows for that?
If the latency becomes problematic (e.g. higher memory usage than expected), an alternative is to go through the Query mechanism, which can allow for polling and updating the result in shared memory (and even send an IPC for asynchronous notification) to avoid round trips. But I don't think it's necessary at this point?

Thanks,
Antoine
"""

And for those curious, ccameron's design doc: https://docs.google.com/document/d/1hrbvV0ayk5Yw29VtmdDIZO13q9ABacznT8yugWCnDkk/edit

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

commit 23fa660b47e7a5fdadd6303eb966cc31a51d4b5e
Author: erikchen <erikchen@chromium.org>
Date: Tue Jun 14 23:50:05 2016

Add a new command buffer function glScheduleCALayerInUseQueryCHROMIUM.

The function allows the client to asynchronously query whether a texture is
still in use by the MacOS Window Server.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_schedule_ca_layer.txt
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/GLES2/gl2chromium_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/GLES2/gl2extchromium.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/build_gles2_cmd_buffer.py
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_c_lib_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_cmd_helper_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_implementation_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_implementation_impl_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_implementation_unittest_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_interface_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_interface_stub_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_trace_implementation_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/client/gles2_trace_implementation_impl_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/cmd_buffer_functions.txt
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/common/gles2_cmd_format_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/common/gles2_cmd_format_test_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/common/gles2_cmd_ids_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/service/gles2_cmd_decoder_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doer_prototypes.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doers.cc
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_handlers_autogen.cc
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/ipc/service/image_transport_surface_overlay_mac.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/gpu/ipc/service/image_transport_surface_overlay_mac.mm
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/ui/gl/gl_enums_implementation_autogen.h
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/ui/gl/gl_surface.cc
[modify] https://crrev.com/23fa660b47e7a5fdadd6303eb966cc31a51d4b5e/ui/gl/gl_surface.h

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

commit 1ed6908a7a46dde512db953c77e343a63f41630f
Author: erikchen <erikchen@chromium.org>
Date: Mon Jun 20 18:27:27 2016

Pass responsibility for IOSurface-texture reuse to the gpu process.

The GLRenderer uses the new command buffer function
glScheduleCALayerInUseQueryCHROMIUM to determine whether textures are still in
use by the system compositor. This means that GpuMemoryBufferIds no longer need
to be plumbed through to the browser process.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/DEPS
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/direct_renderer.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/gl_renderer.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/gl_renderer.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/output_surface.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/output_surface.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/output_surface_client.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/overlay_unittest.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/renderer_settings.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/renderer_settings.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/output/renderer_settings_unittest.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/proto/renderer_settings.proto
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/surfaces/display.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/surfaces/display.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/test/fake_output_surface_client.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/cc/trees/layer_tree_host_impl.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/content/browser/compositor/gpu_output_surface_mac.mm
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/command_buffer/common/BUILD.gn
[add] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/command_buffer/common/texture_in_use_response.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/command_buffer_common.gypi
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/client/command_buffer_proxy_impl.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/client/gpu_process_hosted_ca_layer_tree_params.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/common/gpu_command_buffer_traits.cc
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/common/gpu_command_buffer_traits.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/common/gpu_messages.h
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/gpu/ipc/service/image_transport_surface_overlay_mac.mm
[modify] https://crrev.com/1ed6908a7a46dde512db953c77e343a63f41630f/ui/compositor/compositor.cc

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

commit 60af4caf9047de95048aeb2bf4e3cee9e317c62e
Author: ccameron <ccameron@chromium.org>
Date: Mon Jun 20 20:19:35 2016

cc: Remove ScopedReadLockGpuMemoryBuffer

This approach is not going to be used.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/60af4caf9047de95048aeb2bf4e3cee9e317c62e/cc/output/gl_renderer.cc
[modify] https://crrev.com/60af4caf9047de95048aeb2bf4e3cee9e317c62e/cc/output/gl_renderer.h
[modify] https://crrev.com/60af4caf9047de95048aeb2bf4e3cee9e317c62e/cc/resources/resource_provider.cc
[modify] https://crrev.com/60af4caf9047de95048aeb2bf4e3cee9e317c62e/cc/resources/resource_provider.h
[modify] https://crrev.com/60af4caf9047de95048aeb2bf4e3cee9e317c62e/cc/resources/resource_provider_unittest.cc

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

commit 399d94a026f104afe16d129cb587431351b0419d
Author: ccameron <ccameron@chromium.org>
Date: Wed Jun 22 03:08:58 2016

Remove CreateGpuMemoryBufferFromClientId and plumbing

This interface is for an approach that will not be used.

This in effect reverts r396084, r395454, r395040, and r394958.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/blimp/client/feature/compositor/blimp_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/blimp/client/feature/compositor/blimp_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/blink/web_external_texture_layer_impl.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/ipc/transferable_resource.mojom
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/ipc/transferable_resource_struct_traits.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/layers/texture_layer_impl_unittest.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/output/gl_renderer_unittest.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/output/overlay_unittest.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/resource_provider.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/resource_provider.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/texture_mailbox.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/texture_mailbox.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/transferable_resource.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/test/test_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/cc/test/test_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/exo/buffer.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/common/mojo_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/common/mojo_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/gpu/mus_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/gpu/mus_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/surfaces/ozone_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/components/mus/surfaces/ozone_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/content/browser/gpu/browser_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/content/browser/gpu/browser_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/content/child/child_gpu_memory_buffer_manager.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/content/child/child_gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/gpu/command_buffer/client/gpu_memory_buffer_manager.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/gpu/ipc/client/gpu_memory_buffer_impl_io_surface.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/media/base/video_frame.cc
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/media/base/video_frame.h
[modify] https://crrev.com/399d94a026f104afe16d129cb587431351b0419d/media/video/gpu_memory_buffer_video_frame_pool.cc

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

commit 7cb1503e57864170612b6a7ad6dc1b8c52907c44
Author: erikchen <erikchen@chromium.org>
Date: Fri Jul 08 21:53:10 2016

Remove the command buffer method glGetImageivCHROMIUM.

It is no longer necessary, since the browser compositor no longer needs access
to the underlying GpuMemoryBuffers.

This CL is a revert of "Expose GpuMemoryBufferId through glGetImageivCHROMIUM."
> WebKit widgets that provide textures to TextureLayer need to also provide the
> GpuMemoryBufferId if the texture is backed by a GpuMemoryBuffer. This CL
> modifies the CHROMIUM Image extension to allow the GpuMemoryBuffer id to be
> obtained by a new function glGetImageivCHROMIUM.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

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

[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/cc/test/test_gles2_interface.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/cc/test/test_gles2_interface.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/cc/test/test_web_graphics_context_3d.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/cc/test/test_web_graphics_context_3d.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/GLES2/gl2chromium_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/GLES2/gl2extchromium.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/build_gles2_cmd_buffer.py
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/client_test_helper.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_c_lib_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_implementation.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_implementation_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_interface_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_interface_stub_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_trace_implementation_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gles2_trace_implementation_impl_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/client/gpu_control.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/cmd_buffer_functions.txt
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/service/in_process_command_buffer.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/service/in_process_command_buffer.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/tests/gl_manager.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/command_buffer/tests/gl_manager.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/gles2_conform_support/egl/context.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/gles2_conform_support/egl/context.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/ipc/client/command_buffer_proxy_impl.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/gpu/ipc/client/command_buffer_proxy_impl.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/ppapi/proxy/ppapi_command_buffer_proxy.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/ppapi/proxy/ppapi_command_buffer_proxy.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/services/ui/gles2/command_buffer_local.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/services/ui/gles2/command_buffer_local.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/services/ui/public/cpp/lib/command_buffer_client_impl.cc
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/services/ui/public/cpp/lib/command_buffer_client_impl.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/GraphicsTypes3D.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.h
[modify] https://crrev.com/7cb1503e57864170612b6a7ad6dc1b8c52907c44/third_party/WebKit/Source/platform/graphics/gpu/DrawingBufferTest.cpp