Convert Ozone wayland to directly create GLSurfaces.

Convert Ozone wayland to directly create GLSurfaces.

The Ozone wayland platform now directly creates an appropriate GLSurface
instead of creating a SurfaceOzoneEGL. Remove the SurfaceOzoneEGL
subclass and add a new GLSurface subclass.

BUG=611142
Committed: https://crrev.com/ee79ef399c3f4d2e3652981674eac9347e4b6a1a
Cr-Commit-Position: refs/heads/master@{#408631}

[kylechar, 2016-07-26 16:20:55]

Patchset #2 (id:20001) has been deleted

[kylechar, 2016-07-26 16:26:26]

kylechar@chromium.org changed reviewers:
+ rjkroege@chromium.org

[kylechar, 2016-07-26 17:04:46]

kylechar@chromium.org changed reviewers:
+ forney@google.com

[kylechar, 2016-07-26 17:04:47]

+forney for wayland review since it looks like you've been main contributor.

Also worth noting I  haven't figured out how to run wayland ozone platform
yet... I've tried to make sure exactly the same things happen in the same order.
Instead of creating WaylandEglSurface then using that to create a
GLSurfaceOzoneEGL, it just makes a GLSurfaceWayland that contains the right
logic.

[rjkroege, 2016-07-26 21:36:20]

On 2016/07/26 17:04:47, kylechar wrote:
> +forney for wayland review since it looks like you've been main contributor.
> 
> Also worth noting I  haven't figured out how to run wayland ozone platform
> yet... I've tried to make sure exactly the same things happen in the same
order.
> Instead of creating WaylandEglSurface then using that to create a
> GLSurfaceOzoneEGL, it just makes a GLSurfaceWayland that contains the right
> logic.

code looks reasonable. But you should definitely test before landing. Sorry.

[rjkroege, 2016-07-26 21:36:29]

https://codereview.chromium.org/2187443003/diff/40001/ui/ozone/public/surface...
File ui/ozone/public/surface_factory_ozone.cc (right):

https://codereview.chromium.org/2187443003/diff/40001/ui/ozone/public/surface...
ui/ozone/public/surface_factory_ozone.cc:27: return true;
Other platforms not in tree may be relying on the previous default behaviour.

[Michael Forney, 2016-07-26 22:57:59]

On 2016/07/26 17:04:47, kylechar wrote:
> +forney for wayland review since it looks like you've been main contributor.
> 
> Also worth noting I  haven't figured out how to run wayland ozone platform
> yet... I've tried to make sure exactly the same things happen in the same
order.
> Instead of creating WaylandEglSurface then using that to create a
> GLSurfaceOzoneEGL, it just makes a GLSurfaceWayland that contains the right
> logic.

You can test with software rendering by commenting out
https://chromium.googlesource.com/chromium/src/+/master/content/browser/compo...,
building with 'ozone_platform_wayland = true' and 'target_os = "chromeos"', then
running `chrome --ozone-platform=wayland --no-sandbox`. You can start any
wayland compositor that supports wl_shm and xdg_shell (most do), for example
weston.

The EGL support relies on having a single process for InitializeUI and
InitializeGPU. So `chrome --mash` should work (until the process separation
happens). I went to try to test your patch, but ran into a build failure due to
the CreateNativePixmapFromHandle prototype changing. I sent out
http://crrev.com/2185863002 to fix that.

When I try to run from HEAD with --mash, I get an assertion failure at
https://chromium.googlesource.com/chromium/src/+/master/ui/gl/init/gl_factory....
I haven't bisected to find out when this started failing.

When I run after patching this CL, I get a similar assertion failure, this time
at wayland_surface_factory.cc:161.

[kylechar, 2016-07-28 19:39:01]

On 2016/07/26 22:57:59, Michael Forney wrote:
> On 2016/07/26 17:04:47, kylechar wrote:
> > +forney for wayland review since it looks like you've been main contributor.
> > 
> > Also worth noting I  haven't figured out how to run wayland ozone platform
> > yet... I've tried to make sure exactly the same things happen in the same
> order.
> > Instead of creating WaylandEglSurface then using that to create a
> > GLSurfaceOzoneEGL, it just makes a GLSurfaceWayland that contains the right
> > logic.
> 
> You can test with software rendering by commenting out
>
https://chromium.googlesource.com/chromium/src/+/master/content/browser/compo...,
> building with 'ozone_platform_wayland = true' and 'target_os = "chromeos"',
then
> running `chrome --ozone-platform=wayland --no-sandbox`. You can start any
> wayland compositor that supports wl_shm and xdg_shell (most do), for example
> weston.
> 
> The EGL support relies on having a single process for InitializeUI and
> InitializeGPU. So `chrome --mash` should work (until the process separation
> happens). I went to try to test your patch, but ran into a build failure due
to
> the CreateNativePixmapFromHandle prototype changing. I sent out
> http://crrev.com/2185863002 to fix that.
> 
> When I try to run from HEAD with --mash, I get an assertion failure at
>
https://chromium.googlesource.com/chromium/src/+/master/ui/gl/init/gl_factory....
> I haven't bisected to find out when this started failing.
> 
> When I run after patching this CL, I get a similar assertion failure, this
time
> at wayland_surface_factory.cc:161.

Hmm, I managed to get weston running on my machine but version 1.3 doesn't have
xdg_shell. I'll have to load another distribution up in a VM I think? How do you
test your wayland egl changes?

Also, the assertion failure moving is expected since it's the same check for
what GLImplementation that moved. I'm not sure why it's not using egl with
wayland but I'll be able to see better once I get it running.

[kylechar, 2016-07-28 21:22:46]

I got Weston 1.11 running on a VM. Running "./chrome --mash --no-sandbox
--ozone-platform=wayland" draws parts of the mash interface both at ToT and with
this change. Neither of them work well but there are no regressions from the
change I could see.

https://codereview.chromium.org/2187443003/diff/40001/ui/ozone/public/surface...
File ui/ozone/public/surface_factory_ozone.cc (right):

https://codereview.chromium.org/2187443003/diff/40001/ui/ozone/public/surface...
ui/ozone/public/surface_factory_ozone.cc:27: return true;
On 2016/07/26 21:36:29, rjkroege wrote:
> Other platforms not in tree may be relying on the previous default behaviour.

This will at least give them a bit of warning the default behaviour is going to
be deleted shortly. I've made another CL to flip this switch before wayland is
tested and the old codepath gets deleted.

[rjkroege, 2016-07-28 22:11:17]

lgtm

[kylechar, 2016-07-29 12:48:01]

The CQ bit was checked by kylechar@chromium.org

[commit-bot: I haz the power, 2016-07-29 12:48:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-29 13:47:04]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-07-29 13:48:53]

Description was changed from

==========
Convert Ozone wayland to directly create GLSurfaces.

The Ozone wayland platform now directly creates an appropriate GLSurface
instead of creating a SurfaceOzoneEGL. Remove the SurfaceOzoneEGL
subclass and add a new GLSurface subclass.

BUG=611142
==========

to

==========
Convert Ozone wayland to directly create GLSurfaces.

The Ozone wayland platform now directly creates an appropriate GLSurface
instead of creating a SurfaceOzoneEGL. Remove the SurfaceOzoneEGL
subclass and add a new GLSurface subclass.

BUG=611142

Committed: https://crrev.com/ee79ef399c3f4d2e3652981674eac9347e4b6a1a
Cr-Commit-Position: refs/heads/master@{#408631}
==========

[commit-bot: I haz the power, 2016-07-29 13:48:54]

Patchset 3 (id:??) landed as
https://crrev.com/ee79ef399c3f4d2e3652981674eac9347e4b6a1a
Cr-Commit-Position: refs/heads/master@{#408631}