The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91c50202bdc063ddb898c62c84eb183fbb317759

commit 91c50202bdc063ddb898c62c84eb183fbb317759
Author: kylechar <kylechar@chromium.org>
Date: Thu Sep 15 15:59:58 2016

Default to EGL instead of GLX with Ozone X11.

There is a bug destroying one of the XWindows created for the
VSyncProvider. When that bug is fixed the default should be GLX again.

BUG= 646982 

Review-Url: https://codereview.chromium.org/2339413002
Cr-Commit-Position: refs/heads/master@{#418879}

[modify] https://crrev.com/91c50202bdc063ddb898c62c84eb183fbb317759/ui/ozone/platform/x11/x11_surface_factory.cc

Hey Kyle, wanted to check in and get an update on this bug - thanks :)

I haven't had a chance to look at it yet :(

When this bug is fixed (i.e. GLX is the default), the --show-overdraw-feedback flag will work correctly with ozone-x11 on a desktop build. Until then, we need to explicit use --use-gl=desktop for the overdraw flag to work.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a684564707cab9131ffeb1eba84cf1b92beb03fb

commit a684564707cab9131ffeb1eba84cf1b92beb03fb
Author: kylechar <kylechar@chromium.org>
Date: Wed Jun 21 14:47:49 2017

Make --use-gl=desktop default for Ozone X11.

This switches Ozone X11 from --use-gl=egl as the default to
--use-gl=desktop. This is consistent with X11 CrOS build. Desktop GL
uses GLX which has better driver support.

Ozone X11 didn't use --use-gl=desktop originally because there was a
crash running mus when closing XWindows. I can't reproduce the original
crash from  crbug.com/646982  but the problem has to do with shutdown
order. In mus we destroy the PlatformWindow before the GPU destroys the
GLSurface for that window. GLX adds a nested XWindow inside that
PlatformWindows XWindow. When the outer XWindow is destroyed all nested
XWindows are also destroyed. The GPU ends up calling XMakeCurrent() on
an XWindow that has been destroyed.

Change the shutdown order in mus-ws to avoid this problem.

Bug:  646982 
Change-Id: Ieaf764df1417cf740e6a316f91055435029c970e
Reviewed-on: https://chromium-review.googlesource.com/537032
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#481205}
[modify] https://crrev.com/a684564707cab9131ffeb1eba84cf1b92beb03fb/services/ui/ws/window_server.cc
[modify] https://crrev.com/a684564707cab9131ffeb1eba84cf1b92beb03fb/ui/ozone/platform/x11/x11_surface_factory.cc

This should be fixed. I can't actually reproduce the original bug anymore but have fixed a related bug in mus.

halliwell@: If the error still reproduces for cast tests then it's probably shutdown order related.

I can't reproduce this any more on latest build, seems to be fixed :)

With ctrl+d developer shortcut working mustash I can reproduce the original problem again. It's exactly the same issue, we are not destroying the GL things for the AcceleratedWidget before we destroy the PlatformWindow (and it's XWindow).

I finally tracked down why this works in non-mustash Chrome. There is a sync IPC from browser to gpu to destroy GL things that happens before the PlatformWindow is destroyed.

https://cs.chromium.org/chromium/src/gpu/ipc/client/command_buffer_proxy_impl.cc?sq=package:chromium&dr=CSs&l=952