Create new GLSurface for cross process image transport.

Create new GLSurface for cross process image transport.

Currently cross process image transport (on OSX and TOUCH_UI) uses the WebGL code path to render to a texture via FBO. This makes a clean break with path and centralizes the GL context specific IPC communication in one location.

By separating from the WebGL code, I was able to avoid wasting a texture attached to the FBO in the decoder (the old code ignored this attachment --- the new code makes no such attachment at the decoder level).

As a test of the new architecture, I have also implemented XComposite/GLX_texture_from_pixmap image transport (i.e. it's now possible to use the --use-gl=desktop backend on touch_ui builds).

BUG=none
TEST=3D CSS and WebGL on TOUCH_UI.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=93681

[jonathan.backer, 2011-07-16 18:54:11]

This is a cut of some refactoring that I've wanted to do for a while. I'd love
some early feedback if you have it. I'd eventually like to have OSX on a similar
code path.

[apatrick_chromium, 2011-07-18 18:24:10]

I like the direction. One thing, GpuSurfaceStub already implements Listener and
Sender and is assigned an IPC route ID and automatically receives message sent
to the GpuChannel. I intended to handle the IPCs there. Obviously you've put
EGLImsageTransportSurface somewhere where the dependencies are fine. I just
wonder though if you ran into something that prevented you from using
GpuSurfaceStub and, if that is the case, whether we should remove it.

[jonathan.backer, 2011-07-21 20:33:39]

Ready for review. It needs a merging of GpuChildThread and GpuChannelManager to
make deps happy. I'll do that in a separate CL that lands first.

If you can think of a cleaner way than creating the surfaces in the
GpuCommandBufferStub, I'm all ears.

[apatrick_chromium, 2011-07-21 21:03:02]

http://codereview.chromium.org/7395020/diff/16001/chrome/browser/renderer_hos...
File chrome/browser/renderer_host/accelerated_surface_container_touch.cc
(right):

http://codereview.chromium.org/7395020/diff/16001/chrome/browser/renderer_hos...
chrome/browser/renderer_host/accelerated_surface_container_touch.cc:167: dpy,
fbconfigs.get()[config], pixmap_, pixmapAttribs);
This will be out of bounds if there is no suitable config.

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/gpu_chan...
File content/common/gpu/gpu_channel_manager.cc (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/gpu_chan...
content/common/gpu/gpu_channel_manager.cc:34: static int last_id = 0;
Is this the first time we've had to add routed objects on this channel? Wow.

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
File content/common/gpu/image_transport_surface_linux.cc (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
content/common/gpu/image_transport_surface_linux.cc:352:
gfx::NativeViewGLSurfaceGLX::SwapBuffers();
Out of interest, why does it not need to unschedule and reschedule in this case?

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
File content/common/gpu/image_transport_surface_linux.h (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
content/common/gpu/image_transport_surface_linux.h:33: virtual bool
Initialize();
I guess we should start using OVERRIDE.

[jonathan.backer, 2011-07-22 13:12:39]

http://codereview.chromium.org/7395020/diff/16001/chrome/browser/renderer_hos...
File chrome/browser/renderer_host/accelerated_surface_container_touch.cc
(right):

http://codereview.chromium.org/7395020/diff/16001/chrome/browser/renderer_hos...
chrome/browser/renderer_host/accelerated_surface_container_touch.cc:167: dpy,
fbconfigs.get()[config], pixmap_, pixmapAttribs);
On 2011/07/21 21:03:02, apatrick_chromium wrote:
> This will be out of bounds if there is no suitable config.

Done.

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/gpu_chan...
File content/common/gpu/gpu_channel_manager.cc (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/gpu_chan...
content/common/gpu/gpu_channel_manager.cc:34: static int last_id = 0;
On 2011/07/21 21:03:02, apatrick_chromium wrote:
> Is this the first time we've had to add routed objects on this channel? Wow.
AFAIK. I'm pretty disappointed that ChildThread doesn't vend route_ids (same
with MessageRouter for that matter). It seems pretty fundamental functionality.
And if they did vend, I wouldn't have to worry about it.

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
File content/common/gpu/image_transport_surface_linux.cc (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
content/common/gpu/image_transport_surface_linux.cc:352:
gfx::NativeViewGLSurfaceGLX::SwapBuffers();
On 2011/07/21 21:03:02, apatrick_chromium wrote:
> Out of interest, why does it not need to unschedule and reschedule in this
case?
My first implementation had it. Then I dropped it.

The driver implementation seems to take care of double buffering (which is no
surprise seeing as the extensions are designed for an window manager working
asynchronously). Without the unschedule and reschedule, there's no guarantee
that the browser displays this frame (and not the next one for example), but I'm
OK with that. So far no evidence of tearing.

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
File content/common/gpu/image_transport_surface_linux.h (right):

http://codereview.chromium.org/7395020/diff/16001/content/common/gpu/image_tr...
content/common/gpu/image_transport_surface_linux.h:33: virtual bool
Initialize();
On 2011/07/21 21:03:02, apatrick_chromium wrote:
> I guess we should start using OVERRIDE.

Done. But we're not overriding anything here. This class isn't a GLSurface.
Making it non-virtual.

[jonathan.backer, 2011-07-22 13:41:58]

I fixed the deps issue by realizing that GpuChannelManager didn't actually need
a GpuChildThread* when a ChildThread* would suffice.

[apatrick_chromium, 2011-07-22 17:53:42]

LGTM