PorteuX shipped a benchmark alongside its 2.8 release that does something most Wayland versus X11 comparisons do not: every test binary carries both a real X11 backend and a native Wayland one, and picks between them at startup, so nothing is quietly running through XWayland. The finding the project states plainly is that Wayland is intrinsically faster than X11 but not necessarily more efficient. On a Ryzen 7 7840HS with Radeon 780M graphics, the sessions that burned the least power and the least CPU were not the Wayland ones. LXDE with Openbox came first, and Xfce running the project's own xfwm4-gl fork came second.
The short answer
PorteuX published wmbench alongside its 2.8 release, a window manager benchmark in which every test binary carries both a native X11 backend and a native Wayland one and chooses at startup, so results are not distorted by XWayland. Frame rate is measured flat out, while CPU and power are measured with the same workload locked at sixty frames per second. The project's summary is that Wayland is intrinsically faster than X11 but not necessarily more efficient. On a Ryzen 7 7840HS with Radeon 780M graphics, the lowest power and CPU came from LXDE with Openbox, then Xfce with xfwm4-gl.
Almost every Wayland versus X11 benchmark you have read has a compatibility layer somewhere in it. That is the thing wmbench is built to avoid, and it is why the result is worth reading even if you have stopped caring about this argument.
The methodology is the news
PorteuX published wmbench alongside its 2.8 release. The design decision that matters is that every test binary ships two rendering backends, a real X11 one and a native Wayland one, and picks the appropriate one when it starts.
That sounds minor and it is not. In most published comparisons at least one side is running through XWayland, so part of what is being timed is translation between protocols rather than either protocol on its own terms. Remove that and you are comparing the stacks rather than the bridge between them.
The tool also refuses to fake coverage. It probes which protocols a given compositor actually implements and skips the tests it cannot run honestly on that compositor, instead of reporting whatever a fallback path produces. Alongside the performance runs there are nine visual defect tests, covering tearing, stale frames, menu artefacts, screen suspension behaviour and resize glitches, which is the category of problem that benchmarks usually ignore and users usually notice first.
Speed and efficiency are measured differently
This is the detail that makes the headline coherent rather than contradictory.
Frame rate is measured with the benchmark running as fast as it can, windowed and fullscreen. That answers the question of what the stack is capable of when nothing constrains it.
CPU usage and power draw are measured with the same benchmark locked at sixty frames per second. Every session is then doing an identical, fixed amount of work, and the question becomes how much silicon and how many watts it took to do it. Power readings come from hardware sensors on the CPU and GPU. On X11 the CPU accounting covers the window manager and the X server, and on Wayland it covers the compositor.
Measure speed uncapped and efficiency capped, and it becomes entirely possible for one protocol to win the first and lose the second. That is exactly what happened.
What came out on top
On frame rate, Wayland led. KDE Plasma on Wayland performed strongly, along with labwc and COSMIC.
On power and CPU the ranking inverted. The test machine was a Ryzen 7 7840HS with Radeon 780M integrated graphics and 32 GB of RAM running PorteuX 2.8, and the sessions that drew the least power and used the least CPU were not the Wayland ones. LXDE with Openbox came first, with Xfce running xfwm4-gl second.
The project's own summary is worth taking at face value: Wayland is intrinsically faster than X11, but not necessarily more efficient, and for compositing specifically, which excludes Openbox, xfwm4-gl was the best of the set.
That exclusion matters. Openbox does no compositing at all, so it is not doing the same job as a compositor managing buffers and per frame presentation. Reading it as a competitor overstates the case. Reading it as the floor, the cost of compositing expressed in watts, is more useful.
xfwm4-gl, the fork in second place
xfwm4-gl is a fork of Xfce's xfwm4 maintained by the PorteuX developer, adding OpenGL compositing to a window manager whose reputation has always been low overhead with a modest compositor attached.
Placing second on both power and CPU, behind only a session doing no compositing whatsoever, is a strong showing for a fork rather than an upstream rewrite. If you run Xfce on a laptop and care about battery life, it is worth knowing about.
How to read this if you run desktops
One machine, one distribution, integrated AMD graphics. That is the scope, and the project has been more careful about stating it than most.
Within that scope the practical conclusion is narrow and useful. If battery life is the thing you are optimising, a light X11 session with minimal compositing is still competitive on 2026 hardware, and in this test it won. If frame rate, latency, mixed refresh rates or fractional scaling are what you care about, none of this argues against the reasons people moved to Wayland in the first place, and the Wayland side of the ecosystem has kept shipping.
The more durable contribution is the tool. A benchmark that carries both backends natively, skips tests it cannot run honestly, and separates uncapped speed from capped efficiency is a better instrument than the arguments it will be used to settle. The X11 side of the world is not standing still either, as a Rust X11 server reaching Steam and GPU workloads suggests. Having a fair way to measure both is overdue.
Sources and further reading
- Wayland Found To Be "Intrinsically Faster Than X11, But Not Necessarily More Efficient", Phoronix, August 2026
- Wayland vs X11: Faster on Frames, Not on Watts, and an Xfce Fork Beats Both, Hardware Busters, August 2026
- wmbench: benchmarks and visual defect tests for Linux window managers, GitHub
- xfwm4-gl: a compositor forked from Xfce xfwm4 with OpenGL compositing, GitHub
Frequently asked questions
What makes wmbench different from previous comparisons?
It removes the compatibility layer from the measurement. Most Wayland versus X11 numbers you see involve at least one application running through XWayland, which means part of what is being timed is translation rather than the protocol itself. In wmbench each test binary ships both a native X11 backend and a native Wayland one and selects the right one when it starts. The tool also probes which protocols a given compositor actually speaks and skips the tests it cannot run honestly on that compositor, rather than reporting a number produced by a fallback path.
How are frame rate, CPU and power measured?
They are measured under different conditions on purpose, which is the part that makes the headline finding coherent. Frame rate is measured with the benchmark running flat out, windowed and fullscreen, to see what the stack can do when nothing is holding it back. CPU usage and power draw are measured while the same benchmark is locked at sixty frames per second, so every session is doing an identical, fixed amount of work. Power comes from hardware sensors on the CPU and GPU. Measuring speed uncapped and efficiency capped is why one protocol can win the first and lose the second.
Does this mean I should go back to X11?
No, and the result does not really support that reading. What it supports is that if battery life on a laptop is your dominant concern, a lightweight X11 session with little or no compositing is still competitive, and in this test it won. That is a narrow claim about one machine with integrated AMD graphics running one distribution. It says nothing about multi monitor mixed refresh rate setups, fractional scaling, touchpad gestures or the several other areas where Wayland is the reason people moved. Pick the axis you actually care about and measure it on your own hardware.
Is comparing Openbox to a Wayland compositor fair?
Not exactly like for like, and the project says as much. Openbox does no compositing at all, so it is not doing the same work as a compositor that is managing buffers, effects and per frame presentation. That is precisely why the project qualified its own conclusion: excluding Openbox, the most efficient compositing session in the test was Xfce with xfwm4-gl. The Openbox result is still useful information, because it puts a number on what compositing costs you, but it should be read as the floor rather than as a competitor.
What is xfwm4-gl?
It is a fork of Xfce's xfwm4 window manager, maintained by the PorteuX developer, that adds OpenGL compositing. Standard xfwm4 has long been the lightweight option that pays for it with a less capable compositor, and this fork is an attempt to keep the low overhead while moving the compositing path onto the GPU. In this benchmark it placed second on both power and CPU, behind only a session doing no compositing at all, which is a good result for a fork rather than an upstream rewrite. The source is on GitHub.