Implement GLX for Ozone X11.

content/gpu/gpu_main.cc

Index: content/gpu/gpu_main.cc
diff --git a/content/gpu/gpu_main.cc b/content/gpu/gpu_main.cc
index 4e47b7cf25ef56a0ce57f24a248563c971cde3d2..d68ff4afc45e10c63fd1d210912a5fe8c41f3b02 100644
--- a/content/gpu/gpu_main.cc
+++ b/content/gpu/gpu_main.cc
@@ -185,12 +185,15 @@ int GpuMain(const MainFunctionParams& parameters) {
   // create child windows to render to.
   base::MessagePumpForGpu::InitFactory();
   base::MessageLoop main_message_loop(base::MessageLoop::TYPE_UI);
-#elif defined(OS_LINUX) && defined(USE_X11)
+#elif defined(USE_X11)
   // We need a UI loop so that we can grab the Expose events. See GLSurfaceGLX
   // and https://crbug.com/326995.
   base::MessageLoop main_message_loop(base::MessageLoop::TYPE_UI);
   std::unique_ptr<ui::PlatformEventSource> event_source =
       ui::PlatformEventSource::CreateDefault();
+#elif defined(USE_OZONE)

[piman, 2016/09/06 22:17:55]

Is it the case that Ozone + X11 doesn't have USE_X11 set?

Note, you will go through this path on Chrome OS (which has USE_OZONE=1), so you
are changing the message loop from TYPE_DEFAULT to TYPE_UI. Is it really what
you want? Shouldn't we have a OZONE+X11 case that is distinguished from, e.g.
OZONE+Freon (Chrome OS)?

[kylechar, 2016/09/07 13:47:16]

Yep, Ozone X11 has USE_OZONE=1 and USE_X11=0.

It's definitely the case I don't totally understand the implications of changing
the message loop type. Does TYPE_UI use significant additional resources so it
can poll for native events? Is there some other drawback to using TYPE_UI?

The only issue with checking what Ozone platform we're running before picking
the type of message loop is that Ozone hasn't been initialized yet. I think the
Ozone initialization could be moved before here, or if that isn't possible then
I could add a different way to check what message loop type is needed for an
Ozone platform before it's initialized.

[piman, 2016/09/07 17:07:09]

Depending on the platform, there are constraints such as:
1- there can be only 1 UI loop per process
2- it requires a connection to the UI framework (e.g. X11) which can take longer
to initialize
3- posting tasks to the loop is more costly because it needs to integrate into
the poll() loop, i.e. write on a pipe (requiring syscalls) as opposed to just
adding a task to the queue which can be done with a simple mutex/cv (futex).

1 doesn't apply here (or, it's already a constraint anyway, so nbd)
2 probably is a noop on Ozone+Freon
3 is probably the bigger deal. It's probably hard to quantify.

Surely Ozone must compile without X present (since we removed X headers on
Chrome OS Freon boards) - Is there no compile-time define that we can use to
limit this to builds that have X11?

[kylechar, 2016/09/07 21:10:42]

Thanks! That makes more sense about the message loop types.

Yep, Ozone compiles with X present. There is the GN args ozone_platform_x11 that
is only true when compiling Ozone X11. We could add some preprocessor define
based on that flag and check it here. Although, you can build Ozone GBM and X11
in the same binary. In that case you don't know until runtime what type of
message loop is needed.

[piman, 2016/09/07 21:44:30]

I think the important case is that if X11 is not present (for Chrome OS), we
keep a DEFAULT message loop. So, testing the absence of X11 (since it wouldn't
be there on Chrome OS) to trigger DEFAULT, and using UI otherwise.

[kylechar, 2016/09/13 19:59:12]

That's fair. Added a #define in content/gpu/BUILD.gn and I'm checking it here.

+  // Ozone X11 needs a UI loop to grab Expose events. https://crbug.com/326995
+  base::MessageLoop main_message_loop(base::MessageLoop::TYPE_UI);
 #elif defined(OS_LINUX)
   base::MessageLoop main_message_loop(base::MessageLoop::TYPE_DEFAULT);

[piman, 2016/09/07 17:07:09]

If the answer to the question above is no, this is probably unreached at this
point (maybe #error)

[kylechar, 2016/09/13 19:59:12]

Done.

 #elif defined(OS_MACOSX)