Overview

GL Layers are not enabled by default on X11. The primary problem was that there were interoperability issues between X11 rendering APIs (RENDER) that render into X pixmaps and OpenGL. Most of these were due to Gecko's incorrect use of the texture_from_pixmap extension (fixed in bug 707722) and issues with Mesa's glXWaitX and glXWaitGL (worked around in bug 687831).

The rest of this page was written assuming that texture_from_pixmap problems were insurmountable, and so we'd need to stop using XRender, stop using X pixmaps, to be in a place to easily enable GL layers by default. However, there are no known obstacles to using X Pixmaps with GL. Remaining work is identified in dependencies of bug 594876.

Getting rid of X-specific APIs have several other advantages:

• It is a step forward in the direction of supporting Wayland.
• It reduces the number of platform specific APIs (Mac, Fennec and B2G use OpenGL), and makes it easier for us to write new features that work on several platform out of the box (or almost), including Linux.

Removing use of RENDER acceleration for drawing will cost in performance in some situations. Expected areas include:

• Compositing of glyphs for text.
• Compositing of images in canvas.

GL layers should benefit performance where subpixel aa text in a translucent layer is scrolled over a fixed background. (Black-white component-alpha extraction is not possible with RENDER API and full component-alpha 2D rendering for basic layers would require major changes deep into cairo.) It is hoped that the benefits for subpixel aa text in translucent layers outweigh the cost of compositing glyphs in software. There may also be benefits in client-side CPU rendering with complex paths. An OpenGL canvas implementation is required also for other platforms, so that will save us from removing gpu acceleration of canvas.

Some known limitations:

• We cannot have GTK2 and GTK3 symbols in the same address-space.
• plugins like Flash need GTK2.
• GTK2 needs XLib surfaces for native widget rendering (GTK3 relaxes this constraint by decoupling the gtkStyleContext from the widget, meaning that you can render a native widget into a cairo surface rather than an XLib surface).

So a prerequisite for getting rid of X surfaces is to use GTK3 instead of GTK2.

Action plan

1. Add support for compiling with GTK3. bug 627699
2. Use basic layers for shaped windows. bug 630346
3. Workaround system-cairo issues. bug 583035
   • GTK3 support, at this stage at least, requires --enable-system-cairo.
4. Install GTK3 on build machines. Create and test GTK3 builds.
   • depends on system-cairo workarounds.
5. Add GL canvas implementation.
6. Add support for GTK2 plugins with GTK3 builds bug 624422.
7. Check whether we need to do anything special to render windowless plugins with GL/tfp when UseXRender() is false.
8. Add (or modify) and run a reftest target with gfx.xrender.enabled and layers.acceleration.force-enabled.
9. Make gfxPlatformGtk::UseXRender() return false with GL layers in GTK3 builds.
   • depends on GTK3 compiling, GL canvas, tfp plugins.
10. Upgrade NVIDIA drivers on talos machines. bug 684165 for bug 680817.
11. Switch GTK3 builds to use GL layers when available.
    • depends on all above steps.