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.

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.

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.

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.

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.

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.

well according to post, coz they are very similar. but xwayland doubles it

which is still half a frame at best so I think any blame here would be just on a particular game being slow on inputs

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.

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.

Yeah at 120hz each frame is 8ms. So you're only missing a single frame around 30% of the time.

I certainly want my latency as low as I can get it. But I'm pretty skeptical that anyone is truly feeling the difference of a couple ms.

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.

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).

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.

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.