Make GPU back-pressure work with remote CALayers

Make GPU back-pressure work with remote CALayers

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

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289232

[ccameron, 2014-08-09 01:12:35]

This is the back-pressure change that we discussed earlier.

[ccameron, 2014-08-12 05:08:30]

The usual suspects are at SIGGRAPH/OOO, jbauman, can you get this (I'll TBR them
for OWNER bits).

[jbauman, 2014-08-12 21:27:53]

lgtm

[ccameron, 2014-08-12 22:00:30]

Thanks!

[ccameron, 2014-08-12 22:00:35]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2014-08-12 22:10:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ccameron@chromium.org/454243002/20001

[commit-bot: I haz the power, 2014-08-13 04:00:29]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_x64_rel on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[commit-bot: I haz the power, 2014-08-13 09:37:50]

Change committed as 289232

[Ken Russell (switch to Gerrit), 2014-08-15 20:19:30]

LGTM after the fact. Sorry for not getting to this before leaving.