Support for ozone graphics in content and gpu/

content/common/gpu/image_transport_surface_ozone.cc

Index: content/common/gpu/image_transport_surface_ozone.cc
diff --git a/content/common/gpu/image_transport_surface_android.cc b/content/common/gpu/image_transport_surface_ozone.cc
similarity index 77%
copy from content/common/gpu/image_transport_surface_android.cc
copy to content/common/gpu/image_transport_surface_ozone.cc
index 2d8ee4373d8f30b7b74343acd212879610a1a6e4..1cc195de9986b763ac360f42b3da6f7284793106 100644
--- a/content/common/gpu/image_transport_surface_android.cc
+++ b/content/common/gpu/image_transport_surface_ozone.cc
@@ -1,4 +1,4 @@
-// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Copyright (c) 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
@@ -7,6 +7,7 @@
 #include "base/logging.h"
 #include "content/common/gpu/gpu_command_buffer_stub.h"
 #include "content/common/gpu/gpu_surface_lookup.h"
+#include "ui/base/ozone/surface_factory_ozone.h"
 #include "ui/gl/gl_surface_egl.h"
 
 namespace content {
@@ -16,16 +17,14 @@ scoped_refptr<gfx::GLSurface> ImageTransportSurface::CreateNativeSurface(
     GpuChannelManager* manager,
     GpuCommandBufferStub* stub,
     const gfx::GLSurfaceHandle& handle) {
-  DCHECK(GpuSurfaceLookup::GetInstance());
   DCHECK_EQ(handle.transport_type, gfx::NATIVE_DIRECT);
-  ANativeWindow* window =
-      GpuSurfaceLookup::GetInstance()->AcquireNativeWidget(
-          stub->surface_id());
+
+  gfx::AcceleratedWidget window =
+      ui::SurfaceFactoryOzone::GetInstance()->GetAcceleratedWidget(
+          handle);

[piman, 2013/05/21 21:28:56]

This feels weird. The intent of the GLSurfaceHandle is to pass the
AcceleratedWidget from the browser to the GPU process (in the case where the
GLSurfaceHandle represents a native surface).
Could we call whatever GetAcceleratedWidget does on the browser side, and then
pass it through GLSurfaceHandle.handle ?

Basically, taking a step back, is: how do you see unit tests (e.g.
compositor_unittests) work, given that they don't use the content layer? They
create a WebGraphicsContext3DInProcessCommandBufferImpl passing in the
AcceleratedWidget directly from the compositor.

[rjkroege, 2013/05/22 17:20:05]

I was going down the wrong path here. The changes we discussed yesterday make it
unnecessary to alter this file.

   scoped_refptr<gfx::GLSurface> surface =
       new gfx::NativeViewGLSurfaceEGL(false, window);
   bool initialize_success = surface->Initialize();
-  if (window)
-    ANativeWindow_release(window);
   if (!initialize_success)
     return scoped_refptr<gfx::GLSurface>();