Comment 49 for bug 2023322

Ok. The problem is that while the WebKit process chooses a depth-32 X11 visual for its window (in PlatformDisplayX11::visual), the associated GLXFBConfig doesn't actually have an alpha channel. So it ends up rendering in RGB.

It looks like Chromium devs struggled with a similar problem years ago [1]. There's not really a reliable way to choose a suitable X11 visual without calling into GLX, so fixing this might be a bit tricky with the current architecture.

Also, a separate issue is that GLContextGLX::createWindowContext includes "GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, GL_FALSE" in its glXChooseFBConfig criteria, which causes that function to fail to find any configs. Is there a reason for doing that? SRGB framebuffers are disabled by default even if the config supports them, so it shouldn't be necessary, right?

Regardless, though, even if that criterion is removed, it will find a config but glXMakeCurrent will fail because you can't make an XRGB drawable current to an ARGB context. So the visual thing also needs to be fixed somehow.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=369209