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.
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.
Great article! Thank you. Also in case others walked away with the same question I had, I'll save you the googling: use the utility vrrtest to help validate if VRR is properly configured on your machine.
From the "Similar Efforts" section toward the bottom:
---
David Ramiro built his m2p-latency and compared X11 vs Wayland in his article Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric) as well, coming to similar conclusions:
Native Wayland is on par with native X11 (all tied at ~7 ms), while XWayland roughly doubled the latency in his tests.
farnoy did extensive testing with the Open-Source-LDAT in his post Linux latency measurements and compositor tuning, also concluding that XWayland should be avoided.
I switched my daily driver / gaming rig to Fedora a few months back.
Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions.
I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is gaining in popularity.
I’ve considered using gamescope to hopefully get in front of some of these concerns, but I’m on nvidia and there is some discussion about it not working well there.
Now the author's got me thinking about gaming-optimized kernels, which I did not realize was a thing.
I play competitive fighting games so input latency is a huge concern. Would love to hear from anyone else who’s been down this path.
I use gamescope on a separate TTY that directly launches either steam or heroic launcher. I find this works exceptionally well. No window manager needed as you are playing a game full screen anyway. It fixed some other things like HDR too but at a loss of the volume and brightness keys no longer working.
There's no such thing as "Wayland input latency". It's just a word salad, akin to "HTTP animation smoothness". The post is measuring Xorg vs. KWin (and also XWayland), other implementations of either X11 or Wayland will have different characteristics.
I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.
This is an annoying style of argument from Wayland fans.
Wayland fan: You need to switch to Wayland. X is deprecated and has been for years! Wayland is the future.
User: Okay, I tried, and it's broken/worse.
Wayland fan: No, you don't understand, Wayland is just a protocol. It's your implementation of Wayland that is at fault, not Wayland itself! Wayland is still great!
This is awesome. I would like to see tests like this done at 60 Hz as well, and also with non-3D apps. I suspect the results might look different in those conditions. A 500 Hz monitor is not the common case. 2ms is a whole frame!
One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful. These results will get reported back to the graphics software authors and the distribution packagers and the ecosystem will improve. There's no sense with Microsoft that kind of improvement is possible.
I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than Windows 11. Also the feeling that if something isn't working right I can probably tinker and improve it. It's been really nice. If you haven't tried Linux desktops in awhile give Bazzite a whirl: it's a Fedora customized for gaming. Even if you don't game it's an easy way to get a very functional Linux desktop in no time at all.
> These results will get reported back to the graphics software authors and the distribution packagers and the ecosystem will improve. There's no sense with Microsoft that kind of improvement is possible.
It wouldn’t surprise me if Microsoft could turn a knob and get telemetry data from millions of devices, and feed that back to the software graphics authors.
> One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful.
If only they'd actually DO something with this meaningfulness. I love and use Linux as my daily driver, but desktop environments and everything around it have become so complicated yet worse than before.
In the past a simple config file with intuitive setting names inside of them could make you do anything you wanted.
Today they have all these layers of abstraction for themes, icon sets and light and dark mode and what not, but almost NO combination works!
If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere. And even if not involving light or dark mode, same misery with whatever themes like "Adwaita" and others, some things will work in one, other things in another, I've seen a PDF viewer that made everything black text on black background in some desktop themes... A PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it?
No theme I found anywhere has _well visible_ scrollbars, they all seem to love making them as subtle as possible so you can hardly see where your scroll position actually is. No theme I found anywhere has a _clear visual distinction_ (different color, not just a subtle shade difference) for the selected window vs the non selected ones. This would be _extremely_ handy for knowing in what window you're typing now, even windows 3.11 got this (and the scrollbars, and the ability to customize your colors) better
While not latency, it's still a thing they just can't get right, and when things were less overdesigned it actually worked better, so what was all this for?
Desktop environments have improved so many times over IMO. KDE and Gnome are legitimately high-performance and extremely usable - more so than Windows or Mac in my experience.
Yes theming in particular has gotten complex, but that's largely because of the application domain. We now abuse electron for everything. And, if it's any consolation, it's still 100x better than Windows, which can't decide on less than 12 themes for its own built-in applications, let alone third-party apps.
Bazzite or CacheyOS (if you wish to do gaming and have more rope to hang yourself mainly because you can more easily affect the system if it isn’t trying to enforce immutability).
TBH with the onslaught of LLM CLI’s like Claude I am a lot more promiscuous in my Linux OS choices as of late. I used to stick to Ubuntu because that was the Linux I knew, but the “interface” has become the same to me because I just ask Claude to help me achieve a semantic goal without having to score the web for the appropriate keys.
Who knows, maybe I’ll eventually swing the other way and give NixOS a try finally.
I stand by my comments. Bazzite has benefits being immutable but immutability can cause certain tasks to be more involved or constrained. Case in point it’s nice that Bazzite comes with a lot of sane defaults:
- brew
- podman
But it would be disingenuous to understate the additional hurdles either you or software you are accustomed to using being amenable to operating within the immutability restriction. That’s not to discount the great benefits and entire categories of problems that immutability protects you from. It’s just a priority and weighing your options question.
Here’s an example that bit me: I wanted to run k3s/k0s but both have issue with Bazzite. Those were hard stops for me.
> Also the feeling that if something isn't working right I can probably tinker and improve it
And thats exactly where free software shines. Enough people fixing issues they deem worthy of spending time on means the overall software will only improve with time.
You forgot to mention that Xlibre is run by a conspiracy theorist, who broke Xorg by having multiple bugs in his Merge Requests and is well known in the kernel mailing list for spreading vaccine misinformation and getting called out by Linus Torvalds personally for it
It looks like consoles and PCs have settled on somewhat different gaming configurations. Consoles usually try to target a fixed output frame rate, while the resolution is often dynamic. On PCs, by contrast, the resolution stays static, while the frame rate and frame-time pacing are dynamic. How does this fit into the latency discussion?
Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Am I out of touch, or is it the children with colored LEDs on their DRAM sticks who are wrong?
Consoles are more and more supporting VRR, as are televisions.
But yes, given the limitations of the hardware, they often offer two modes - a high framerate but lower quality mode and a high quality but lower framerate mode.
>I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Pixel refresh is only one part of latency. A higher framerate will lower several other parts of the overall latency. Monitors Unboxed has charts that visualize the amount of latency for each step.
"Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect."
Depends on the engine. Anyone remember Quake 3's multiple of 3 frame rate speed hack?
I have found that input latency is a LOT more acceptable with a controller than it is with a mouse.
Playing a cinematic game with a controller (especially with auto-aim) at 30FPS with vsync is fine. Playing a first person shooter with a mouse, or a game where you control your camera with a mouse, at 30FPS with vsync feels very bad.
That's my theory on why the priorities are different, at least.
It's chronoception effect, not placebo effect. Standard literature claims humans can readily visually perceive 60-90Hz, and perhaps somewhere 500-1000Hz for ghosting. Note that all this is somewhat tangential to the article which focuses on _input latency_, I think the author is driving the high refresh just to minimize _output latency_ as much as possible from the test.
The Rock Band guitars have a photoresistor for precisely this purpose: the screen flashes and the guitar responds when the light hits it. It helps make the otherwise very painful calibration process transparent.
It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. Here are some open tabs I've got in case anyone's curious:
I have a vague memory of (X?)Wayland being much worse than X11 before, and some patch or protocol making it out to all the relevant implementations, but I might have imagined that, since these result show virtually no difference, and only XWayland shows a marginal difference.
Or maybe it just came out of nowhere and was never true.
gamescope is a custom wayland compositor that Valve built for gaming...
In steam big picture mode there is no xwayland or anything, just gamescope.
What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).
gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...
When rendering 60fps on a 60Hz display every frame takes approximately 16ms to render. Then you have to add TV latency that’a probably around 20ms unless you have a very nice OLED TV. Wireless controller latency is around 8ms I think? Then your imperfect human brain adds even more latency especially when you’re tired after work. That 3ms is not perceivable. Make that 5ms even. Nobody would be able to tell a difference in a blind test.
Linux is underrated and is only getting better. I am building a linux cloud platform so we can build unity and Godot games with mcps right in your browser. Not only is Linux the only option but I have realized it is the best option for AI
Using Wayland (hyprland) for daily driver and it's the happiest I've been with an OS in a long time on feel. Feels crisp in that spartan way that windows & macos just don't - no animations, taskbar, popups or god knows what else.
This used a 500Hz display which hides a lot of the problems that would show up on slower displays.
The XWayland result is 3ms slower, which at refresh rates this high makes me wonder if it was one frame behind.
Running the tests at 120Hz or even 60Hz might be more interesting because we could start to separate out very small differences in timing from the much larger effects of being a full frame behind.
I am not super familiar with Wayland, but basically how composited rendering under X11 works, is if you have a fullscreen window, you can give an 'unredirect' hint to the compositor, in which case when nothing else is drawing your screen, it will stop compositing, and pass your app's swapchain directly to the screen.
This is pretty much optimal, and you can't really do much better than this.
Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.
Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.
Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.
Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.
I wonder though, updated pixels might not have the same latency on the whole screen, and it might even be affected by some updates mechanisms, like panel replay. I.e. it would have been interesting to also measure the screen position as a dimension.
Also, both the input latency (usb controller, and its driver), and screen latency (input latency + processing + update delay) are supposedly also affecting all measurements, but hopefully somewhat consistent or at least filtered out.
I wonder what is considered "unnecessary programs" by the author. Is "apparmor" or sandboxing considered in this? Or just user space applications (browser, discord, …).
I wonder if input latency would be improved if you ran setup as `root`. I wouldn’t do it for security sake, but just curious
86 comments
[ 2.7 ms ] story [ 70.0 ms ] threadNo. Wayland is slow on its own. You can test it without Xwayland.
Wayland is fine. People should use AMD and KDE Plasma.
I'd avoid Nvidia to begin with.
edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency
---
David Ramiro built his m2p-latency and compared X11 vs Wayland in his article Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric) as well, coming to similar conclusions:
Native Wayland is on par with native X11 (all tied at ~7 ms), while XWayland roughly doubled the latency in his tests.
farnoy did extensive testing with the Open-Source-LDAT in his post Linux latency measurements and compositor tuning, also concluding that XWayland should be avoided.
I switched my daily driver / gaming rig to Fedora a few months back.
Everything seems snappier compared to Windows, but not sure if it’s in my head, and I’ve been very curious about gaming input latency. This helps answer some questions.
I recently switched to hyprland and I’m very interested how that fits in these results. hyprland uses Wayland so I hope the author might revisit now that hyprland is gaining in popularity.
I’ve considered using gamescope to hopefully get in front of some of these concerns, but I’m on nvidia and there is some discussion about it not working well there.
Now the author's got me thinking about gaming-optimized kernels, which I did not realize was a thing.
I play competitive fighting games so input latency is a huge concern. Would love to hear from anyone else who’s been down this path.
I wonder where the XWayland's added latency comes from though, it seems suspiciously high to just be easily hand-waved as overhead.
Wayland fan: You need to switch to Wayland. X is deprecated and has been for years! Wayland is the future.
User: Okay, I tried, and it's broken/worse.
Wayland fan: No, you don't understand, Wayland is just a protocol. It's your implementation of Wayland that is at fault, not Wayland itself! Wayland is still great!
User: But X was working fine...
I recently switched to Linux after years on Windows desktop, mostly because the KDE Plasma desktop feels snappier than Windows 11. Also the feeling that if something isn't working right I can probably tinker and improve it. It's been really nice. If you haven't tried Linux desktops in awhile give Bazzite a whirl: it's a Fedora customized for gaming. Even if you don't game it's an easy way to get a very functional Linux desktop in no time at all.
Even better, most of the tech stack is open source and contributions are welcome!
It wouldn’t surprise me if Microsoft could turn a knob and get telemetry data from millions of devices, and feed that back to the software graphics authors.
Certainly both Intel (https://www.techpowerup.com/312122/psa-intel-graphics-driver...) and Nvidia (https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) collect such data themselves (opt-in in both cases, so they may not get much data from the most hard-core gamers)
If only they'd actually DO something with this meaningfulness. I love and use Linux as my daily driver, but desktop environments and everything around it have become so complicated yet worse than before.
In the past a simple config file with intuitive setting names inside of them could make you do anything you wanted.
Today they have all these layers of abstraction for themes, icon sets and light and dark mode and what not, but almost NO combination works!
If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere. And even if not involving light or dark mode, same misery with whatever themes like "Adwaita" and others, some things will work in one, other things in another, I've seen a PDF viewer that made everything black text on black background in some desktop themes... A PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it?
No theme I found anywhere has _well visible_ scrollbars, they all seem to love making them as subtle as possible so you can hardly see where your scroll position actually is. No theme I found anywhere has a _clear visual distinction_ (different color, not just a subtle shade difference) for the selected window vs the non selected ones. This would be _extremely_ handy for knowing in what window you're typing now, even windows 3.11 got this (and the scrollbars, and the ability to customize your colors) better
While not latency, it's still a thing they just can't get right, and when things were less overdesigned it actually worked better, so what was all this for?
Yes theming in particular has gotten complex, but that's largely because of the application domain. We now abuse electron for everything. And, if it's any consolation, it's still 100x better than Windows, which can't decide on less than 12 themes for its own built-in applications, let alone third-party apps.
TBH with the onslaught of LLM CLI’s like Claude I am a lot more promiscuous in my Linux OS choices as of late. I used to stick to Ubuntu because that was the Linux I knew, but the “interface” has become the same to me because I just ask Claude to help me achieve a semantic goal without having to score the web for the appropriate keys.
Who knows, maybe I’ll eventually swing the other way and give NixOS a try finally.
Here’s an example that bit me: I wanted to run k3s/k0s but both have issue with Bazzite. Those were hard stops for me.
And thats exactly where free software shines. Enough people fixing issues they deem worthy of spending time on means the overall software will only improve with time.
Xlibre is an actively developed and maintained X11 protocol display server.
Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!
https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrb...
Would you run and rely on TempleOS? Then XLibre is for you!
Especially in competitive gaming, I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Am I out of touch, or is it the children with colored LEDs on their DRAM sticks who are wrong?
But yes, given the limitations of the hardware, they often offer two modes - a high framerate but lower quality mode and a high quality but lower framerate mode.
>I often see people targeting frame rates way beyond their display’s refresh rate. I’m not sure whether this actually provides a real benefit or whether they’re chasing a placebo effect.
Pixel refresh is only one part of latency. A higher framerate will lower several other parts of the overall latency. Monitors Unboxed has charts that visualize the amount of latency for each step.
Depends on the engine. Anyone remember Quake 3's multiple of 3 frame rate speed hack?
Playing a cinematic game with a controller (especially with auto-aim) at 30FPS with vsync is fine. Playing a first person shooter with a mouse, or a game where you control your camera with a mouse, at 30FPS with vsync feels very bad.
That's my theory on why the priorities are different, at least.
It would be so cool to get that to work in Linux. I know the instrument code is in hid-sony. Here are some open tabs I've got in case anyone's curious:
- https://pascal.giard.info/techreports/nguyen-daniel-autocali...
- https://www.niangames.com/articles/reverse-engineering-rockb...
- https://github.com/torvalds/linux/blob/master/drivers/hid/hi...
Or maybe it just came out of nowhere and was never true.
>Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
What you are reading from the readme notes that it calls into xwayland only when gamescope (wayland compositor) is nested within another compositor (say kwin or mutter).
gamescope itself is wayland only, and when run on SteamOS is has no xwayland latency...
When rendering 60fps on a 60Hz display every frame takes approximately 16ms to render. Then you have to add TV latency that’a probably around 20ms unless you have a very nice OLED TV. Wireless controller latency is around 8ms I think? Then your imperfect human brain adds even more latency especially when you’re tired after work. That 3ms is not perceivable. Make that 5ms even. Nobody would be able to tell a difference in a blind test.
The XWayland result is 3ms slower, which at refresh rates this high makes me wonder if it was one frame behind.
Running the tests at 120Hz or even 60Hz might be more interesting because we could start to separate out very small differences in timing from the much larger effects of being a full frame behind.
Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.
This is pretty much optimal, and you can't really do much better than this.
Once a stray window appears on top, or something makes the compositor think it can't do this, it'll do the intermediate step of compositing your app window with others into a temp buffer, and render that.
Sometimes the unredirect breaks for some reason (I remember a case where for some inexplicable reason my app kept creating a window 1px smaller than the screen height), or you use XWayland, you get bad latency.
Since this is a fundamental constraint, other compositors on different OSes must work like this, and you can run into issues like this as well.
Another thing - Wayland afaik started exporing 'display planes' - which are a HW feature of GPUs, that allow it to composite multiple layers together - which means the game can render at full FPS and all the windows on top will be drawn into a different plane and get composited with no ill effects - not sure if this is actually used in production yet.
Also, both the input latency (usb controller, and its driver), and screen latency (input latency + processing + update delay) are supposedly also affecting all measurements, but hopefully somewhat consistent or at least filtered out.
I wonder what is considered "unnecessary programs" by the author. Is "apparmor" or sandboxing considered in this? Or just user space applications (browser, discord, …).
I wonder if input latency would be improved if you ran setup as `root`. I wouldn’t do it for security sake, but just curious