Support for ozone graphics in content and gpu/

Support for ozone graphics in content.

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

[rjkroege, 2013-05-21 18:35:51]

The content follow-on to 13886018. Please take a look after that CL seems baked.

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

https://codereview.chromium.org/14985005/diff/2001/content/common/gpu/image_t...
File content/common/gpu/image_transport_surface_ozone.cc (right):

https://codereview.chromium.org/14985005/diff/2001/content/common/gpu/image_t...
content/common/gpu/image_transport_surface_ozone.cc:24: handle);
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]

ptal.

https://codereview.chromium.org/14985005/diff/2001/content/common/gpu/image_t...
File content/common/gpu/image_transport_surface_ozone.cc (right):

https://codereview.chromium.org/14985005/diff/2001/content/common/gpu/image_t...
content/common/gpu/image_transport_surface_ozone.cc:24: handle);
On 2013/05/21 21:28:56, piman wrote:
> 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.

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

[piman, 2013-05-22 17:23:22]

lgtm

[commit-bot: I haz the power, 2013-05-23 20:05:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rjkroege@chromium.org/14985005/8001

[commit-bot: I haz the power, 2013-05-23 20:05:31]

Failed to apply patch for content/content_gpu.gypi:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file content/content_gpu.gypi
  Hunk #1 FAILED at 13.
  1 out of 1 hunk FAILED -- saving rejects to file content/content_gpu.gypi.rej

Patch:       content/content_gpu.gypi
Index: content/content_gpu.gypi
diff --git a/content/content_gpu.gypi b/content/content_gpu.gypi
index
fc1c6bad7c14d6973504deaecbcb86b06ef7233e..ad628cac69a1aa8a27a511dae264eff12dfd2aa0
100644
--- a/content/content_gpu.gypi
+++ b/content/content_gpu.gypi
@@ -13,6 +13,7 @@
     'gpu/gpu_dx_diagnostics_win.cc',
     'gpu/gpu_info_collector_android.cc',
     'gpu/gpu_info_collector_mac.mm',
+    'gpu/gpu_info_collector_ozone.cc',
     'gpu/gpu_info_collector_win.cc',
     'gpu/gpu_info_collector_x11.cc',
     'gpu/gpu_info_collector.cc',

[rjkroege, 2013-05-28 22:24:17]

piman: this is substantially the same as the previous revision except for
merging across zmo's large refactor. Take another look?

[piman, 2013-05-28 22:42:01]

lgtm

[commit-bot: I haz the power, 2013-05-28 22:49:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rjkroege@chromium.org/14985005/31001

[commit-bot: I haz the power, 2013-05-29 02:28:30]

Change committed as 202749