He seems confused at the end why people think wayland is so slow, but don't you think it's because of his xwayland result? People were probably running x11 games on wayland and noticed that significant lag. Just a wild guess. Very nice article, wish people did actual measurements like this more often, of all sorts of things.
You can't just test one wayland compositor and talk about the performance of all wayland compositors. They're vastly different, especially when it comes to the extensions to wayland needed to handle input devices (ref: https://wayland.app/protocols/). It's not like how xorg is the standard strong reference implementation for X11 everywhere that works the same everywhere.
What's probably happening is that other wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.
You will also get different results by gpu, compiler, kernel, architecture, and then of course compositor. Even a slightly different version of some lib might throw off the results.
In any case the methodology in the post is sound and should be used for benchmarking in the future.
The methodology works and it's a fine result. But it's important to remember that talking about one wayland is not talking about all waylands the way talking about xorg/X11 is.
And FWIW, KDE probably make the most effort with their compositor. They have historically been well ahead of the curve for things that might affect this (e.g. VRR).
Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.
The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.
I think the author’s use of a 500Hz display covers up or minimizes a lot of issues. It’s really easy to look at this data and say 8ms click to flash is fabulous even though he has an config that does 4ms.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.
This[1] study suggests image framerate does not significantly affect our ability to perform predicted moves accurately in time, above a certain minimum which is lower than 24 Hz.
Moving the mouse and then pressing a button, or pressing one key and then another, are both cases of predictive moves.
So it seems one shouldn't rely on framerate when talking about the limits of sensing input lag, at least in general.
You might be right, 8 ms of total end to end latency is about 1 frame at 120 hz or half a frame of 60 hz, someone would need to be quite competitive to notice that. And the baseline was 4 ms, so going from half a frame of total e2e latency at 120 hz to 1 frame, not much of a difference. Also in 2026 I'm realizing it might be doubtful that many games would still be only x11, so I'm not sure how common it would be to encounter xwayland in a game today realistically.
Isn't Wayland always one frame delayed compared to Xorg to avoid tearing or has that been changed? If so, his very high refresh rate would minimize that effect
I don't think there was ever a design to be one frame behind.
Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").
Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.
Yes, but the same is true in Wayland and it's automatic as well. Full screen applications don't require compositing so they typically don't, and this was the case in MOST X11 compositors as well.
Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.
Those results depend on having a 500hz monitor. There's a world of difference between a mildly-buggy rendering loop's 1-frame delay or missing a vsync deadline causing a 2ms delay vs a 16ms delay.
Tearing can theoretically improve latency for the part of the screen that's below the tear, but in any case where you could actually benefit from it the difference would be at least order of magnitude smaller than the duration of one frame.
I've been using Linux since the mid 1990's. I'm no newbie to any of this. I literally can't tell the different between X11 and Wayland when using either of them and I don't care about all the arguing. This is just Vim vs Emacs and Gnome vs KDE all over again. At this point when I see people complaining about it I just click off the page. It's all stupid and pointless.
My biggest problem with wayland was how it was basically forced on the community. It broke innumerable things for years, put all the responsibility for implementing things down on the DEs and WMs themselves.
All of this hassle, forcing so much more work on DE/WM devs, for the sake of 'better security' in scenarios that don't really apply to 99% of linux users, with the promise of 'better latency' which this very article proves is false.
I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken, and I'm now using linux mint xfce edition, as hopefully by the time xfce drags itself to wayland, all the bugs and tooling will be a solved problem.
I don't know enough about this to have a favorite, just know the transition was rough. Like one day at work our DE had to get changed because of whatever reasons they couldn't use X anymore, and that affected more things like Chrome Remote Desktop. Years after I tried setting up Linux on an old PC and learned that Wayland is de facto default now, but not in Mint, even though Mint is supposed to be the easy one... and CRD was still finicky in either one.
Linux is about choice, but unless you're ready to write a lot of things yourself, it's outside your control how well parts of the ecosystem are supported. For an average user it's unacceptable for your entire GUI to suddenly change in a way that requires relearning, something that Mac and Windows have avoided doing at least since 2000. Even Win8 or Mac26 wasn't so disruptive. It's possibly worse for an average Linux user because they aren't just concerned with how it looks but also compatibility with advanced things like X forwarding or VNC or CRD.
I think Linux is about choice some folks opinions notwithstanding. It's an ecosystem where many different devs have chosen to go about the same thing many different ways. You the user then get to pick from amongst those varied and interesting choices.
It however isn't about all or indeed any of those devs being obligated to support any particular choice. You can only buy a place at the table with money or sweat and merely using something isn't contributing and doesn't get you a vote.
Arguably the problem isn't the display server its the fact that general linux usage tends to require a little understanding of what's going on under the hood than is strictly speaking desirable for joe average user especially when something doesn't work. EG needing to understand that your choice of display server is making your zoom calls not work and then having to open that whole can of worms.
The fix is honestly more labor. The trivial way to acquire more labor is with money which is hampered by the fact that so little is paid. If you want more polished stuff pay more.
No. If you tell users they should switch to a new display server, you shouldn't be surprised if no one takes you up on it if you don't provide basic feature parity.
If you tell DE/WM devs they should use your new protocol, but say it's now their responsibility to do all these things that the old display server did for them, don't be surprised if it doesn't get much traction.
I don't for the life of me understand why wayland took off. It's provided no benefit to the average user, or DE/WM dev, and a whole lot of hassle.
Was there some other reason distros switched to Wayland? I've always heard X11 was just not maintained well and had too much tech debt, not so much about the security.
From what I remember, Wayland is a thinner layer than X11, basically handing clients pointers to shared buffers for them to write into, which seems better than X11's server approach. Thought maybe people were eager to switch for latency reasons, but this benchmark is showing otherwise. And would think Wayland is more efficient too, but I haven't noticed or heard of a difference.
And the attitude of just refusing to make things work because haha fuck you that's why. I think it was Kicad or Gimp or Blender where you can drag windows onto other windows to merge them and they had to add a warning saying this will never work on Wayland because Wayland doesn't want it to work.
It is absolutely not the DE/WM devs driving this, it's the wayland folks saying that xorg would no longer be maintained. They literally just dumped an Ikea box of protocols on the table without even bothering to provide a decent sample implementation and said 'good luck!'
2. There are currently many high-quality implementations, Kwin being the best IMO.
3. X11 devs didn't want to maintain it, nobody "made them" stop. You or I could maintain it, but I also don't want to, so, here we are.
4. Yeah the wayland transition was rough but I think there's basically no universe where that transition would be perfect. They're architecturally different things. The Apple Intel to M series transition wasn't perfect either and there were A LOT of bugs. These things just happen.
1. Their sample implementation was bad, I think it was just a demo app for car displays or some such. They should have ported over a simple wm.
2. Yeah, the major projects like gnome and kde had enough developers to dedicate to porting over to wayland. Most existing DEs and WMs found the porting process to be very difficult and didn't even bother. This would have been solved had they released an implementation with feature parity. See #1.
3/4. I don't care. I consider xorg to be 'feature complete'. There are few benefits to the end user switching to wayland beyond some niche use cases like multi-display scaling, and HDR. The small benefit of those is nowhere near worth the headache they forced on users when the major DEs started going wayland only.
Overall, I am happy sticking with xfce since it's taking the slow road on moving from xorg to wayland.
Yeah but the display server people are different from the WM/DE people. And the former kinda just said "coding is hard" and made it all the responsibility of the WM/DE people.
And don't forget the “this isn't a wayland problem” whenever a major missing feature provided by the X11 ecosystem is mentioned. Guess what: if you're going to replace the whole ecosystem, you're responsible for all the missing things regardless of your opinions of the matter.
Also waypipe is inferior by design as it is a proxy added after the fact.
But it does not matter that they now have some kind of a solution for a use case for which they denied that it even exists for a long time. I will avoid Wayland because I do not like the direction and the interests that drive it.
> I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken
Yeah, because it wasn't ready. Pretty much no one recommended using it back them, if you thought it was ready you were either misguided or misled. It's time to put your skepticism aside and give it another try, there is a pretty good chance it's going to work great now.
Even Valve Steam OS is now adopting it. It's a pretty good sign wayland is a viable replacement for X11, while bringing it own things.
People were declaring it ready in 2016 10 years ago and talking about how people needed to switch off the working "obsolete" X and switch ASAP to the broken wayland.
It is completely counterfactual that "pretty much no one" was recommending it in 2021
Let's ignore this point of the discussion. For how long do you think users stayed on wayland back in 2016? The vast majority of users experience was... nothing because it wasn't even being shipped by 99% of distros yet, and if they cared to sought it they used it for 5 minutes until it crashed or even 0 minutes because it couldn't even display anything on their graphics card. Very few people actually experienced and tried to use wayland for real back then. Most of them were either devs or enthusiasts.
Fast forward to 2021 and most users experience with wayland was that GDM (on some distros) would try to start on wayland mode but couldn't for some reason and would fallback to X11. Note: I do think that the distros that were pushing for this were being reckless with their users. Introducing it as an opt-in would be much better and would still lower the barrier for testing. Also, KDE didn't even offer a wayland mode, taking until 2024 for it to start defaulting to it and any other wayland desktop had to be sought after by the user.
So really, I think people only started to "suffer" wayland's wonky-ness for the last three to five years depending how you view it. And honestly the last year or two has been pretty usable.
Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal:
- Effort spent writing sway that could have been spent improving i3
- Effort spent writing GNOME-Wayland that could have been spent improving GNOME
- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)
- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors
- Wine/Proton devs needing to waste time getting every windows application to work in Wayland
- Firefox needing to target both Wayland and X
- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort
- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)
What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.
How incredibly arrogant of you. Its their time to spend as they see fit. You get no say in that and complaining they didn't do what YOU wanted them to when YOU wanted them to do it is peak entitlement. Grow up
I'm complaining on these developers' behalf, not bemoaning them doing what they were more or less forced to do. If glibc decided tomorrow to remove the `malloc` function from their library and every C project suddenly had to implement its own allocator, that would be a massive waste of everybody's time, no?
Except it's actually a massive pain in the ass for unrelated projects and users. One example:
Robbert van der Helm has a very popular (in the Linux music editing world) program, yabridge, which enables DAW plugins written for Windows/Mac (aka most of them) to run in Linux DAWs. It leverages Wine and a cascade of transparent window layers that position mouse clicks, menu positions, and graphics updates. It's crude, it's clever, it works. Musicians who love Linux rejoice!
Enter Wayland.
Mouse clicks no longer land where they're supposed to. Reparenting a window doesn't work like it did on X11. Edits to the yabridge source code are a moving target because WINE devs (who are largely paid professionals, which occasionally keeps out a handful of useful merge requests; these maintainers DO need to balance the needs of ALL Wine users with every edit) keep editing winex11.drv (which has all the display and input functionality touched by yabridge), and robbert-vdh shares in some issues that he doesn't have much time to make changes, especially when they might break again later.
For over a year, yabridge is broken.
Advice is given to pin wine-staging 9.21. (Wine 11.0, released 7 months ago, is the current stable version.) Yabridge users share tips on how to install/build Wine 9.21 long after their package manager has deprecated it. You can still run yabridge on newer Wine, mostly; one workaround is to always drag your plugins to the upper-left corner (if the window allows it; I couldn't do this with REAPER in Fedora KDE without disabling snapping, which I want; for months, I used the non-GUI plugin panel in REAPER). A few plugins just stopped working. Sometimes users will log what happens and upload this and it even eventually gets explained---for that specific case---but often not solved right away.
One maintainer of Wine made edits both in Wine and yabridge specifically to get yabridge working again. I don't know if he did it for a CodeWeavers user or just out of the kindness of his CodeWeavers-paid heart. This pull request covered 90% of users, but a few still complained it didn't work in X DAW with Y plugin on Z distro. Because it doesn't always work, it becomes a branch; technical users will be able to manually get their DAW/plugins (often paid, sometimes a subscription, so there's an incentive to use them) to hopefully work and hopefully for the long term.
A few DAWs even change their plugin code to support, say, keyboard passthrough, which should theoretically be handled by Wine or/and yabridge but still has issues. These DAWs could be getting new features or addressing USB interface latency/throughput/routing, but instead they're dealing with fractional scaling, plugin support, themes, and a bunch of other graphical details that worked previously.
It absolutely wastes developer time because now the rules of "who handles what" (in every major distro and DE) have changed for anyone with a GUI and because developers are often users who have no choice in the changes and don't have the background to just know---or the free time to learn---how Windows and Wine and VST and Linux graphics work, and even if they did, the MR/PR they write and submit might not get merged at all in the chain of programs needed to get FabFilter to run in Bitwig on Ubuntu 26.04, because it doesn't also let Auto-Tune run in Ardour on Fedora. (This is contrived, but you can read through the 100+ open yabridge issues yourself to find the actual problems being experienced.)
By the way, the "ya" in yabridge is an abbreviation, "yet another," because it worked where other VST bridges did not. It wasn't the first compatibility layer for VST and won't be the last. Either robbert-vdh will change his codebase to work with the new methods Wine uses to handle Wayland windows, or there will be a new bridge. If you're wondering why there are 20+ actively maintained and reasonably well-known terminal emulators (How many could I rattle off without looking it up? Alacritty, Ptyxis, Foot, Wexterm, Terminator, xterm, Konsole, Guake, Kitty, ghostty, xfce4-terminal, and does Putty count?) it's because of situations like this, where the new paradigm forces old devs to keep up and implement popular feature requests or get replaced.
All of this doesn't even consider whether a DAW is Flatpak or not. (Hint: the failure modes are different.)
-----
Users can't always get old hardware to support the old software that worked. Users can't always get every version of old software they knew to work six/eight/ten years ago. Users on old software have to figure out vulnerability patches and how to handle subscription and dongle-based plugins.
(Windows 11 is a bad experience, I don't even count this as a fallback.)
If the decision makers of Linux are going to make changes that break workflows, they absolutely should get [productive, kind] pushback. We shouldn't have to downgrade our OS UX and free cash reserves to a Mac Studio just to be able to do the things we already could do in 2018.
-----
I suspect video has the same problems. DaVinci Resolve exclusively supports Rocky Linux 8.6 on kernel 4.18. Why would BMD have qualms about targetting a more recent version... unless there's some friction building this support?
This is the complete opposite of those discussions. It's taking a specific quantifiable thing and measuring it, with enough information for anyone to try and reproduce the results.
It's the epitome of science, comparing it to a generic vim vs emacs flamewar which is pure subjective opinion is pretty baseless.
It's really not like Emacs/vim. I use X because it works on my setup and always has, whereas Wayland has not, despite Wayland advocates claiming it's ready and X is deprecated for 10+ years.
I mean normally this type of discussion is silly, but in playing competitive shooters latency does make a huge difference, and it shows that XWayland is adding ~4ms of latency.
There is a native Wayland driver for Wine/Proton but it's enabled through an environment variable, not by default. This will probably be default in Wine 12/Proton 12 because Valve wants to squeeze as much performance out of SteamOS as possible. The gaming mode UI runs under Valve's own Wayland compositor (gamescope) already, but games are currently in nested XWayland windows.
No. Wayland has been in development for 17 years. People have been claiming its been ready for prime time when it wasn't for a surprising portion of that time while it had substantial deficiencies while the boring old shit continued to work fine.
It has been ready for users whose sole usage is an editor a terminal and a browser on their single screen intel laptop as long as they didn't also open youtube since 2015.
Imagine the boss's nephew joins the firm. He knows less than nothing and is worse than useless everything he touches turns to shit. People understandably complain. After 10 years of development and other people's time he is now moderately capable at his job. People still bitch. They aren't lying or wrong. They just aren't current.
To put it in perspective: an average eye blink is 100-150 ms. The worst outcome in this test was with XWayland adding 3ms of latency. Maybe this is truly important for some exceptional pro gamers but for the majority of the world it is as you say, stupid and pointless.
This was with a nvidia 4070 attached to a 500 hz monitor. Even so P95 difference between worst and best was closes to 5ms. Meanwhile 60 hz monitors are incredibly common and every time a 16.7 ms frame deadline it causes an additional 16 ms of latency worse this is inconsistent and spiky and will be noticeable.
The length of a blink is irrelevant. People notice latency especially inconsistent latency. The perception of xwayland being laggy in latency sensitive context like gaming is accurate.
the statements of wayland being slow or not need a lot of context: what version of the game they played, the display server, the game settings, the display server settings, the monitor's feature set, the video card's feature set, the video card driver version, etc.
