GitLab

Prior to this change, ImageTransportSurfaceFBO had the property
that it would un-schedule the GPU channel at a swap, and then
re-schedule the GPU channel when the swap was acknowledged by
the browser process.

Separate out the re-scheduling of the channel into the function
ImageTransportSurfaceFBO::UnblockContextAfterPendingSwap.
Previously, this re-scheduling was done after receiving an ack in
the form of the AcceleratedSurfaceMsg_BufferPresented IPC.

Because the re-scheduling of the GPU channel is no longer blocked
on the AcceleratedSurfaceMsg_BufferPresented IPC, issue that
IPC from the UI thread in the browser when the SwapBuffers IPC
is processed (instead of doing so on the IO thread immediately).
Get rid of the hacks being used prevent the IOSurface from being
freed while the SwapBuffers IPC was bouncing from the IO thread to
the UI thread.

For IOSurface-based ImageTransportSurfaces, re-schedule the GPU
channel immediately, because the ui::Compositor in the browser
process is responsible for "feeling" the GPU back-pressure in its
CompositingIOSurfaceLayer. Prevent the IOSurface from being freed
while it is in-flight by keeping around an extra reference to all
in-flight IOSurfaces (the reference is taken at SwapBuffers and is
released at AcceleratedSurfaceMsg_BufferPresented).

For CAContext/CALayer-based ImageTransportSurfaces, re-schedule
the GPU channel when the ImageTransportLayer in the GPU process is
displayed (the back-pressure is "felt" within the same process).
Because the CAContext used for this ImageTransportSurface is static
for the lifetime of the ImageTransportSurface (unlike IOSurfaces
where re-allocation at resize is common), there is no need to keep
around references to in-flight surfaces.

BUG=312462
R=jbauman
TBR=kbr

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

Cr-Commit-Position: refs/heads/master@{#289232}
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@289232 0039d316-1c4b-4281-b951-d872f2087c98