Firefox Brings the Fire: Shifting from GLX to EGL

You may (or may not) have heard that Firefox is moving from GLX to EGL for the Linux graphics stack. It’s an indicator of which way the tides are moving in the software world. Let’s look at what it means, why it matters, and why it’s cool.

A graphics stack is a complex system with many layers. But on Linux, there needs to be an interface between something like OpenGL and a windowing system like X11. X11 provides a fundamental framework for drawing and moving windows around a display, capturing user input, and determining focus, but little else. An X11 server is just a program that manages all the windows (clients). Each window in X11 is considered a client. A client connects to the server over a Unix process socket or the internet.

OpenGL focuses on what to draw within the confines of the screen space given by the window system. GLX (which stands for OpenGL Extension to the X window system) was originally developed by Silicon Graphics. It has changed over the years, gaining hardware acceleration support and DRI (Direct Rendering Interface). DRI is a way for OpenGL to talk directly to the graphical hardware if the server and the client are on the same computer. At its core, GLX provides OpenGL functions to X11, adds to the X protocol by allowing 3d rendering commands to be sent, and an extension that reads rendering commands and passes them to OpenGL.

EGL (Embedded-System Graphics Library) is a successor of GLX, but it started with a different environment in mind. Initially, the focus was embedded systems, and devices such as Android, Raspberry Pi, and Blackberry heavily lean on EGL for their graphical needs. Finally, however, Wayland decided to use EGL as GLX brought in X11 dependencies, and EGL offers closer access to hardware.

When Martin Stránský initially added Wayland support to Firefox, he used EGL instead of GLX. Additionally, the Wayland implementation had zero-copy GPU buffer sharing via DMABUF (a Linux kernel subsystem for sharing buffers). Unfortunately, Firefox couldn’t turn on this improved WebGL’s performance for X11 (it existed but was never stable enough). Nevertheless, features kept coming making Wayland (and consequently EGL) a more first-class citizen. Now EGL will be enabled by default in Firefox 94+ with Mesa 21+ drivers (Mesa is an implementation of OpenGL, Vulkan, and other specifications that translate commands into instructions the GPU can understand).

Why This Move Matters

As mentioned earlier, EGL has two crucial features: zero-copy shared buffers and partial damage support. Zero-copy means WebGL can be sandboxed and fast. Partial damage means the whole window doesn’t need to be redrawn if only a small part is changed, saving power. This shift also speaks to the ongoing tides in the software world. Slowly but surely, the world is moving towards the EGL/Wayland style of compositing. This change mainly means fewer abstractions and layers and closer access to the hardware. EGL benefits simply from being newer and (hopefully) less buggy with strange edge cases. Additionally, running Wayland natively by default in Firefox rather than through XWayland is a significant shift.

Anecdotally, people who have tried it say the performance gains have been stellar, particularly when watching videos. The shared buffer helps as, for many GPUs, video is decoded (converting the compressed stream like h.264 into a raw bitmap) and then composited. Having a shared buffer and closer access to hardware allows the GPU to transfer that decoded frame directly into the compositor buffer, rather than making a trip to CPU RAM and back out to the GPU for NUMA machines.

To many of us, Firefox and other incredibly complex programs are mysterious boxes of wizardry. A peek inside to see the dedicated people who make them and how they make decisions and weigh tradeoffs is fascinating.

Curious about more Linux internals? Why not dive into a journey to main()?