29 ms·

Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

407 points by hoechst 2mo ago

dosisking 2mo ago
I wonder how FreeBSD X11 compares to Linux X11
cyh555 2mo ago
Is screen tearing enabled for Wayland? Also how's the latency on Linux vs Windows vs MacOS?
overtone1000 2mo ago
This is why I read Hacker News. Thank you.
cgyvbunji 2mo ago
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.
- superkuh 2mo ago
  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/ 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.
  - hparadiz 2mo ago
    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.
    - superkuh 2mo ago
      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.
  - zamalek 2mo ago
    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).
- datakan 2mo ago
  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.
  - deleted 2mo ago
    [deleted]
  - tapoxi 2mo ago
    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.
  - wing-_-nuts 2mo ago
    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.
    - inigyou 2mo ago
      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.
- retatop 2mo ago
  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
  - hackernudes 2mo ago
    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.
    - gf000 2mo ago
      And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.
      - cwillu 2mo ago
        It's generally a single checkbox to turn off compositing in X11, for precisely this reason.
        FeepingCreature 2mo ago
        You can also disable compositing conditionally in KDE, such as when a game window is opened.
        Chu4eeno 2mo ago
        Not in Wayland, the whole point of Wayland is to make stuff the X server + compositor + various other bits into the window manager.
- Aurornis 2mo ago
  > and noticed that significant lag 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.
  - cgyvbunji 2mo ago
    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.
  - mikenew 2mo ago
    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.
    - lightedman 2mo ago
      Try musicians that are used to playing extremely high speed semihemidemisemiquavers. We notice latency. Neil Peart could almost get sample-precise timing, he was so godlike.
      - gf000 2mo ago
        Humans are good at predicting stuff, and they can notice when the expected doesn't happen. But I wouldn't necessarily say that people can notice it everywhere in every state of mind. The medium, context etc all matter a lot.
- its-summertime 2mo ago
  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.
- hulitu 2mo ago
  > but don't you think it's because of his xwayland result No. Wayland is slow on its own. You can test it without Xwayland.
hparadiz 2mo ago
Amazing work. Thank you for putting this together.
shmerl 2mo ago
> A lot of people still use X11 over Wayland because Wayland is said to have much worse input lag Wayland is fine. People should use AMD and KDE Plasma. I'd avoid Nvidia to begin with.
- bigyabai 2mo ago
  AMD's Mesa drivers are better, but if you already have an Nvidia card then you can still use it just fine with Wayland. The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.
  - tfrancisl 2mo ago
    Seconding this. I'm not happy with the fact that the drivers are proprietary, I really prefer FOSS. But, I am tired of having to deal with FUD around performance and issues with NVIDIA devices which simply don't exist at scale. I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.
    - im3w1l 2mo ago
      Firefox is software rendered on linux-nvidia which leads to a bizarre situation of simple web animations lagging on decent computers.
    - shmerl 2mo ago
      I'd say it's deserved, not FUD. Nvidia did improve in some ways, but it's still way too heavy into blob even in case you plan to use it in the future with nvk. Nouveau / nova developers explained that Nvidia pushed a lot more into their firmware than AMD, turning the kernel driver into more of a shim than an actual driver. That's already a big downside.
      - bigyabai 2mo ago
        It's a tradeoff, and if you're not doing any fancy-pants CUDA work then it's a pretty big one. But most people are already using these blob-heavy drivers on Windows, so switching that same system to Linux is not a huge downgrade in terms of usability or stability. It isn't recommended for new Linux PCs, but it's not a dealbreaker for people switching OSes (anymore).
PcChip 2mo ago
I saw a very similar post a month or two ago, is this the same author? edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency https://farnoy.dev/posts/linux-latency
stusmall 2mo ago
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.
esseph 2mo ago
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.
prhn 2mo ago
Awesome article. 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.
- marinhero 2mo ago
  I moved to OpenSuse and have the same experience/opinion. The only caveat I had in Wayland is Game Streaming. Sunshine/Moonlight work but the input lag is noticeable and there are artifacts in the game. I go back and forth between X11 and Wayland just because X11 better for game streaming but in time I'm sure I'll go full-time into Wayland.
  - wing-_-nuts 2mo ago
    When you say game streaming, is this the steam streaming stack?
    - _kidlike 2mo ago
      sunshine + moonlight is the streaming stack. Steam's one is pretty bad, and still only works in X11.
  - _kidlike 2mo ago
    I've set up sunshine + moonlight on Fedora KDE Wayland, and I've played remotely from a different country with unnoticeable input lag (using a gamepad, playing Cyberpunk). The whole thing is even behind WireGuard. I have very fast internet on both sides, both fiber to the home, with only the tablet running moonlight being on WiFi.
seba_dos1 2mo ago
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.
- markasoftware 2mo ago
  Yep, OP should certainly retest under gnome. Im not in the weeds myself but I get the vibe that gnome's wayland compositor is somewhat faster and more carefully designed than kwin (at least, Emacs in pgtk mode does substantially better under gnome, whereas on Kwin it uses substantial cpu when scrolling and even lags a bit at high resolutions)
- School-Cotton 2mo ago
  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! User: But X was working fine...
  - seba_dos1 2mo ago
    Is this some kind of Pavlov's dog reaction? That's not what my comment was about, and even if it was it wouldn't make any sense anyway as KWin had good results in these measurements.
    - cwillu 2mo ago
      It's exactly what your comment was about: the same boring motte and bailey fallacy of “you don't understand, wayland is a protocol” If your protocol you pushed to replace a working implementation invites a dozen poor implementations which people routinely confuse, that's a problem with the protocol and the push to get people to use it.
modeless 2mo ago
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!
NelsonMinar 2mo ago
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.
- mikepurvis 2mo ago
  I think it depends who it is making noise. There are some famous Oculus-era stories about John Carmack tracing display latency issues and then writing lengthy screeds to Samsung engineers to get them to give him lower level access. I bet if someone like him made enough noise, people at MS would pay attention.
  - cwillu 2mo ago
    Sure, but isn't that the point? Needing to be a celebrity to fix something?
- torginus 2mo ago
  This kind of thing is certainly possible under Windows - you can basically patch any kernel API call, replace any COM object instantiation, install filter drivers that intercept any request to and from a device, replace userland DLLs with your own. It's really scary what you can do, to the point that I often asked myself 'why allow this?' - seeing as hits on certain APIs took me to blackhat forums and articles about writing exploits.
  - pbhjpbhj 2mo ago
    Oh sure, but if I just need to troubleshoot why Minecraft-launcher (a first party app) won't launch ... it didn't give any output; it didn't even exist apparently, but only because MS were hiding it, had to crack out Process Explorer just to get something to troubleshoot on ... then it turns out the "turnkey" app from their first-party app store, loading the first-party app, on the same company's OS just failed with no indications to the user at all, not even a "this app crashed". Solution was to cut out as much of MS as possible ... it's just infuriating when it doesn't work, which seems to be all-the-time. More power to Bazzite and Valve, the sooner games app run in other OS the better.
calvinmorrison 2mo ago
X11 is a protocol. Xorg is an end of life'd project run by the Wayland team. Xlibre is an actively developed and maintained X11 protocol display server. Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!
- anthk 2mo ago
  Xenocara does it better than XLibre.
- preisschild 2mo ago
  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 https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrbSuC3d391VyReM4Wb0+JYXXA@mail.gmail.com/ https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrb... Would you run and rely on TempleOS? Then XLibre is for you!
  - calvinmorrison 2mo ago
    He didn't break Xorg because xorg isn't shipping new releases. All developers introduce bugs.
  - tempaccountabgd 2mo ago
    [dead]
dreamlayers 2mo ago
Why isn't Wayland better than X11?
- inigyou 2mo ago
  [flagged]
- seba_dos1 2mo ago
  Because when it's done right it's not the compositor/display server that's the bottleneck.
- preisschild 2mo ago
  Could just be because of the proprietary nvidia driver or its specific to KDE's wayland compositor. We'd need more data.
hs86 2mo ago
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?
- wao0uuno 2mo ago
  [dead]
- Cieric 2mo ago
  As someone who is in the rendering space for work. Having a higher framerate does help, but in a weird way. Basically the start of the frame rendering is what mostly dictates where objects are rendered. By getting a higher framerate the position of objects that you see in game are much closer to their "real" position. So it's less about seeing more frames at that point and more about seeing the most up to date information possible. Technically it could be possible to render the frame in sync with the framerate and just offset the rendering so it finishes right before it's pushed to the screen, but if you're slightly wrong you'll get really bad stuttering and the execution time of gpus and the cpu submitting the work isn't really deterministic.
  - colechristensen 2mo ago
    As the frame rate goes up the lag between the game state and display state goes down. It doesn't matter that the "extra" frames aren't displayed, the frame that is being displayed needs to be as up to date as possible.
    - Cieric 2mo ago
      Yes, thanks for saying it more concisely/clearly than I did. Just cause I understand something doesn't mean I'm good at explaining it.
bsimpson 2mo ago
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: - https://pascal.giard.info/techreports/nguyen-daniel-autocalib-fender-mustang-pro.pdf https://pascal.giard.info/techreports/nguyen-daniel-autocali... - https://www.niangames.com/articles/reverse-engineering-rockband-guitar-controllers https://www.niangames.com/articles/reverse-engineering-rockb... - https://github.com/torvalds/linux/blob/master/drivers/hid/hid-sony.c https://github.com/torvalds/linux/blob/master/drivers/hid/hi...
Telaneo 2mo ago
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.
haunter 2mo ago
SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.
- AlienRobot 2mo ago
  I'm not sure I understand. If X11 software requires a X11 server and you have a Wayland compositor, how do you "avoid" XWayland?
- upboundspiral 2mo ago
  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...
  - seba_dos1 2mo ago
    What you're saying doesn't make any sense. Gamescope is essentially a XWayland-only compositor (with some basic xdg-shell support that's disabled by default). All games on SteamOS go through XWayland. It doesn't yet mean that it suffers from the latency measured in the article, as the problem could very well be in something else, such as how KWin integrates with XWayland or how GPU drivers interact with it (especially that Nvidia drivers have a history of making XWayland suffer).
  - bionade24 2mo ago
    gamescope absolutely can have Xwayland child panes & this is currently the default on SteamOS running games with Proton, unless PROTON_ENABLE_WAYLAND=1 is set in the game options.
- wao0uuno 2mo ago
  Whole 3.13ms? Man idk shit’s unplayable now. 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.
clodecloud 2mo ago
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
Havoc 2mo ago
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.
- bee_rider 2mo ago
  That’s interesting. Hyprland, spartan? It’s the fancy everything-and-the-kitchen-sink tiling WM, isn’t it?
  - Havoc 2mo ago
    Spartan...haha...I mean it's all relative. Certain relative to the other two boxes I use daily - macos & win. I do know it is favoured by ricers with animations & transparency but I just use it to tile stuff. Think I selected it over sway & i3 due to wayland support at the time. Not sure.
- inigyou 2mo ago
  I guess you'd feel the same in i3 or Xmonad as well.
Aurornis 2mo ago
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.
boomskats 2mo ago
A lot of people conflate Wayland being worse than X11 with Gnome on Wayland being worse than Gnome on X11. Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.
- doubled112 2mo ago
  If I understand the semantics of it all correctly, in that sense, there is no such thing as "Wayland". It is all a little bit confusing compared to the X11 ecosystem. You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.
  - boomskats 2mo ago
    That's what I mean though. I've not used gnome for years, but I have a vague memory of gnome/mutter running on a single main thread which used to lock up quite a lot (javascript etc). And because in X it was X that used to manage things like rendering the mouse pointer every frame, whereas in Wayland it flipped to mutter having to do it directly, the stalls were way more obvious in wayland than X, which is where I think a lot of this perception came from. Again, not sure how much of this is accurate, but that's the point I was trying to make.
    - seba_dos1 2mo ago
      Yeah, I believe Mutter is directly responsible for a lot of bad rep Wayland gets. It got better in many areas, but the damage is done.
torginus 2mo ago
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.
feverzsj 2mo ago
Yes, we know wayland is not only slower but also with much less features.
gfxfan 2mo ago
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.
xyst 2mo ago
Very interesting analysis and setup. 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
- hoechst 2mo ago
  Hi, OP here. I just made sure no other user space application were running. Something that basically can be reasonable expected by a person that cares about game performance to do. For example, no one would stop sshd before their gaming session, but closing a Browser is reasonable imo. That said, this is a pure gaming PC with a Desktop Linux installed, it's not like there's a lot running on there in the first place: no 5 random docker containers, no AppArmor and nothing in kernel space other than what comes by default with CachyOS.
ElijahLynn 2mo ago
Wow, love this!! This is what makes HN great!
Benjamin_Dobell 2mo ago
Been dealing with this a bit at Breaka Club. We teach kids to code with a modded version of Overcooked 2!. We stream OC2[1] with our mod preinstalled over WebRTC. This ensures that kids/schools don't have to try and install the mod. This is particularly important since we support running on school provided hardware. Installing a game without a mod would be hard enough. Added advantage though is kids play with a virtual (on screen) gamepad on iPads in Mobile Safari. Game instances run in Docker containers in Kubernetes/k3s atop very outdated nVidia hardware. Given we're already going across the Internet into school networks, we've tried very hard to optimize latency across the board. Using NVidia NVEnc with DMABuf (zero copy) etc. We're unfortunately using XWayland at present so experience the documented input overhead. Although our inputs are virtual devices at this point, so the overhead may be a bit different. Trying to optimize this whole thing end to end has been a challenge. I would say that performance is currently "acceptable". OC2 coding: https://www.youtube.com/watch?v=ITWSL5lTLig https://www.youtube.com/watch?v=ITWSL5lTLig (not streamed in this case) [1] We've bought a limited number of copies of OC2 and pods claim a license on startup. If we're at capacity, kids play something else.
eaf7e281 2mo ago
Really hope to see a Windows result. What if Windows has a latency of 10 ms+. xD
closeneough 2mo ago
How does Windows compare to this?
teodorlu 2mo ago
Very interesting! Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.
- zaik 2mo ago
  > it starts collecting samples from the photodiode (every ~24 µs). They also have repeated measurements which improves the precision.
- ant6n 2mo ago
  For 300 tests, it seems reasonable to report with some more precision on the median.
DarkmSparks 2mo ago
The main issue is with mouse movement rather than clicks tho...
- Night_Thastus 2mo ago
  Clicks and mouse movement do have different latency, but it doesn't matter for this test. The click is the constant part to show relative positioning of X11/wayland/low latency/vrr/etc. The relative performance should be the same ranking for mouse movement, just with different exact values.
  - DarkmSparks 2mo ago
    Different order of magnitude in my experience. Wayland mouse movement lag is/can be/could/was in the order of several hundred milliseconds. Its that that people notice, not 3 or 4ms difference in click response.
criddell 2mo ago
These results are way better than what Dan Luu measured almost a decade ago: https://danluu.com/input-lag/ https://danluu.com/input-lag/ Even if everything else is perfect, display latency on modern panels is 1-3 ms. So all of the input processing and display pipeline can't be taking more than a millisecond or two and that's remarkable.
- throwaway270925 2mo ago
  Well thats also partly because they use a 500hz display in tfa. An update to Dan Luus articles with modern tech like these high refresh displays, fast gamer keyboards/mice etc would be great thought!
saltcured 2mo ago
The input latency that has been driving me crazy lately is the screen unblank latency to allow input to a program. E.g. I have an old laptop running a browser playing some internet radio stream. Eventually the screen blanker (without locking) activates. Some real life event makes me want to hit the space bar to pause music. But the modern screen blank has decided that it should eat/ignore key presses while blank. So hitting the key doesn't pause music. I have to wait for the screen to light up before it will be possible to trigger the pause, and this delay feels interminable! I seem to recall that in the old days the input remained active to the focused window even if the screen was in a power saving state. This power saving was not conflated with screen-lock security etc. I much prefer that. I think this was because DPMS power saving was an underlying X server behavior, not delegated to a screensaver/lock application? I'd also be partially satisfied with the async behavior of old terminal programs. My inputs should be buffered and processed even if the effects haven't returned to the screen yet. Then I could at least hit keys twice and be trained to know that one would unblank, the other would pause, and all would be well (eventually). The current behavior is like having a temporarily numb hand, and being frustrated waiting for sensation to return before I can operate anything!
- wing-_-nuts 2mo ago
  Question, does your monitor have a KVM? Cause I definitely notice this behavior, even on windows and os x with my monitor. I believe it was the same way on linux as well but it's been a minute since I used linux on my desktop
  - saltcured 2mo ago
    This is actually a laptop with its builtin display. Edit to add: I don't think it has too much to do with display latency. It is some convolution of the desktop environment and display server deciding that keyboard input doesn't go to the focused window while it is in this nominal screen blank state. This Fedora 43 on a boring generic Thinkpad.
inigyou 2mo ago
This website uses IP address blocking to censor itself, and deserves to be publicly shamed for it. Here's an archive link: https://archive.is/hrYZ6 https://archive.is/hrYZ6
- hoechst 2mo ago
  Hello, this is my website and I do not know what you mean by this. If you give me technical details (like the subnet your operating out of), I can take a look at it. My webserver is using crowdsec (https://www.crowdsec.net https://www.crowdsec.net) to ban malicious IPs and I would guess that you are somehow unintentionally affected by this. You can also test your IP by entering it into the crowdsec website to see if it is affected.
  - inigyou 2mo ago
    There you go then. Thank you for confirming my determination of IP blocking. The archive link above may work for the users you censor. Paying $1900/month for an IP address blocklist for a website? Yikes.
    - hoechst 2mo ago
      Yes, I am determined to shield my servers from malicious actors and bots that attempt to exploit it. This sometimes can lead to false positives and I am willing and cooperative in rectifying this to allow open access to real people that want to access the services I provide and make sure stuff like this won't happen again. The security and availability of my servers is as important to me as the ability for anyone to access the public services I provide. Which is why I responded to you immediately and asked for your cooperation to help me fix the problem. You not being cooperative helps no one. Not yourself, not other people with the same issue and not me who's trying to fix it. Crowdsec is free btw, I do not pay anything.
      - inigyou 2mo ago
        The most secure shield is to drop 0.0.0.0/0. IP addresses can't be malicious - they are just numbers.
sellmesoap 2mo ago
I appreciate the article, it's cool to see such small differences across all those settings! It says they learned to solder, if you see solder joins that look like those in the first picture, keep learning! Those are some dry joins, which can easily lead to failure, or intermittant signal loss. Soldering can be a touchy sport!
- hoechst 2mo ago
  OP here, thank you for the feedback. I will keep it in mind for the next time I'm soldering something.
  - sellmesoap 2mo ago
    The main trick is getting the pad/component hot enough that you're adding solder to them, not to the iron. The end result should look like the solder is a smooth fillet, not jaggy/crystalized bumps. Now to tweak my nixos gaming rig with your settings thanks to your research!
coldblues 2mo ago
Addressing all the people here talking about latency of under 10ms, I direct you towards these: https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=fE-P_7-YiVM https://www.youtube.com/watch?v=fE-P_7-YiVM https://news.ycombinator.com/item?id=42832155 https://news.ycombinator.com/item?id=42832155
delusional 2mo ago
Hey, I made one of these too[1]. One of the cool things about my implementation is that the sample loop is carefully written in cycle counted assembly to sample the ADC of the teensy 2.0 at the absolute maximum frequency. I like your blogpost a lot more than mine though. [1] Github: https://github.com/DelusionalLogic/Frametime https://github.com/DelusionalLogic/Frametime, Blogpost: https://www.jnsn.dev/posts/frametime/ https://www.jnsn.dev/posts/frametime/, and followup: https://www.jnsn.dev/posts/fastisslow/ https://www.jnsn.dev/posts/fastisslow/
- hoechst 2mo ago
  That's awesome, odd that I did not come across your project when i was researching this. I'll make sure to read your posts and source code.
abc42 2mo ago
Huh. I turned on PROTON_ENABLE_WAYLAND=1 when it became available and didn't notice any change in input lag. Probably one of the many reasons why I'm not a competitive player. I also don't like to play above 60Hz.
- maltelau 2mo ago
  At 60 Hz, there are 16.6 ms between frames, so the ~3 ms improvement from not using XWayland would be very hard to notice visually. Where it can make a difference is that some competitive FPS games have some kind of client side hitscan or lag compensation and often play at high refresh rates, so there it can actually matter that their system reports to the multiplayer server that you clicked in the right place a couple of milliseconds earlier.
  - abc42 2mo ago
    Oh, cool! Thanks for the knowledge.
- account42 2mo ago
  > I also don't like to play above 60Hz. But why?
  - abc42 2mo ago
    Wrong framing. I would need a reason to go above 60Hz, since it doesn't look any better to me and just wastes energy.
    - mfro 2mo ago
      Are you sure you've ever gone above 60hz and 60fps? It is unequivocally agreed to look much better
      - abc42 2mo ago
        I am. It's meh. People like different things.
heyyyshiv 2mo ago
great
somehnguy 2mo ago
Well written article with a lot of interesting info. I do wish there was a comparison to Windows as well though, as a frame of reference.
url00 2mo ago
Something interesting is the author right away wants to isolate and reduce placebo. But surely, latency is all about "placebo" and "vibes" and "feel" is it not? The ultimate test is how it feels to use on a personal level. Of course, where gathering this sort of data _is_ useful is diagnosing and fixing real latency so it obviously has merit. I just think it's ok to lean on taste and experience for most things UI/UX, including latency. Another point, by couching the comparison in a less technical form (for example, rating a configuration/setup out of 5 stars or some similar approach), it protects from being "too methodological" during testing and data-gathering. One possible issue with the author's methods is if there are degenerative cases that are common in the day-to-day experience of a given configuration, they are unlikely to be present during the precise test that they have setup.
- httpsterio 2mo ago
  Can't say that I agree. I play rhythm games on a national level and benchmarking and reducing input latency is very important in those games. The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell. Vibes and latency don't belong in the same sentence at all imo.
  - cwillu 2mo ago
    It's vibes when you don't have the tools to isolate and measure it. It's unfortunate that “vibe” is almost always pejorative these days.
- noAnswer 2mo ago
  > But surely, latency is all about "placebo" and "vibes" and "feel" is it not? Not sure if I can follow but...no?! My first TFT-TV had 2 seconds input lag. Impossible to play video games on it. That has nothing to do with feelings. Already 10ms delay has a measurable effect: https://www.youtube.com/watch?v=5qjSGEOEaXo https://www.youtube.com/watch?v=5qjSGEOEaXo
- tverbeure 2mo ago
__mharrison__ 2mo ago
I need to look into this more. I was trying to vibe code an OBS plug-in just last week to measure sync between audio and video. My system flashed the screen white and played a note. The idea was to have the camera detect monitor brightness and detect the offset from the audio note. I'm practice the brightness of a 40 inch TV didn't seem to impact the video of the insta 360 link webcam. (I ended up vibe coding a Python GUI to quickly allow me to push through video frames and show the audio frequency. I could quickly type 'v' (video) where I clapped and 'a' (audio) where the waveform changed. It would then tell me the offset...
YmiYugy 2mo ago
Seeing a comparison of different Wayland compositors could be very interesting.
tokyovigilante 2mo ago
This is great but it would be even better if 60Hz results were also presented.
casey2 2mo ago
The article stops halfway through. For developers to do serious work fixing the flaws of wayland they need to know what is causing those hiccups that some users are getting. Not just run wayland on a 500hz monitor and say #NOT_A_PROBLEM #WONTFIX
kelvinjps10 2mo ago
Aren't most games in XWayland? so it means that basically most games run way slower in Wayland.
snarfy 2mo ago
A friend commented that since the sensor is not center vertically on the monitor, VRR will win by default.
3abiton 2mo ago
This was a very enjoyable read, and loved the distribution inclusion, rather than point statistics. I hope there are more tests on different factors like GPUs (nvidia vs amd vs intel), screens, mice, and ultimately windows to see if there is really a difference. I don't play competitve gaming, but careful data driven approach would put a lot of the debated questions to rest.
eqvinox 2mo ago
> So, does X11 have lower latency than Wayland? > Yes, but nowhere near enough to explain why Wayland is generally perceived as much worse than X11. Personally speaking: Wayland has massive stutters when the system is under load, most notably on the mouse pointer. X11 doesn't.
cl3misch 2mo ago
This hits a very soft spot for me. My beloved Spelunky 2 has huge input lag "on Linux", which makes it unplayable for me. It's pretty much the reason I keep my Windows 10 install around. I could not come up with a configuration on Linux that avoids the lag. It's extra infuriating that online sources report the game running flawlessly but seem to ignore input lag.
- cl3misch 2mo ago
  Inspired by my own comment I looked into it again and came up with this combination in the game's "launch options", which feels much better: DXVK_CONFIG="dxgi.syncInterval = 0; dxgi.maxFrameLatency = 1; dxgi.maxFrameRate = 60" gamescope -f --immediate-flips -- %command% I didn't know about `DXVK_CONFIG` before. It's the DirectX-Vulkan translation layer with its own framebuffer and latency. I also manually disabled vsync in the game's `local.cfg` XML file. I love where "gaming on Linux" is going. But I have the feeling the hype on Youtube etc. is in part created by content creators, and doesn't faithfully represent the actual situation (surprise!).
billev2k 2mo ago
Contrast is your friend. Or at least mine.
- throwaway270925 2mo ago
  Open the menu and click the paint bucket. It seems to cycle through color themes :)
tsoukase 2mo ago
With so low differences one should always use VRR and not bother about the rest config. Sub-ms differences are impossible to detect.
MobiusHorizons 2mo ago
Interesting analysis! It would be very interesting to see how this compares to windows on the same hardware.

407 points by hoechst 2mo ago

dosisking 2mo ago

I wonder how FreeBSD X11 compares to Linux X11

cyh555 2mo ago

Is screen tearing enabled for Wayland? Also how's the latency on Linux vs Windows vs MacOS?

overtone1000 2mo ago

This is why I read Hacker News. Thank you.

cgyvbunji 2mo ago

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.

superkuh 2mo ago
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/ 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.
- hparadiz 2mo ago
  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.
  - superkuh 2mo ago
    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.
- zamalek 2mo ago
  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).
datakan 2mo ago
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.
- deleted 2mo ago
  [deleted]
- tapoxi 2mo ago
  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.
- wing-_-nuts 2mo ago
  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.
  - inigyou 2mo ago
    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.
retatop 2mo ago
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
- hackernudes 2mo ago
  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.
  - gf000 2mo ago
    And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.
    - cwillu 2mo ago
      It's generally a single checkbox to turn off compositing in X11, for precisely this reason.
      - FeepingCreature 2mo ago
        You can also disable compositing conditionally in KDE, such as when a game window is opened.
        Chu4eeno 2mo ago
        Not in Wayland, the whole point of Wayland is to make stuff the X server + compositor + various other bits into the window manager.
Aurornis 2mo ago
> and noticed that significant lag 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.
- cgyvbunji 2mo ago
  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.
- mikenew 2mo ago
  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.
  - lightedman 2mo ago
    Try musicians that are used to playing extremely high speed semihemidemisemiquavers. We notice latency. Neil Peart could almost get sample-precise timing, he was so godlike.
    - gf000 2mo ago
      Humans are good at predicting stuff, and they can notice when the expected doesn't happen. But I wouldn't necessarily say that people can notice it everywhere in every state of mind. The medium, context etc all matter a lot.
its-summertime 2mo ago
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.
hulitu 2mo ago
> but don't you think it's because of his xwayland result No. Wayland is slow on its own. You can test it without Xwayland.

hparadiz 2mo ago

Amazing work. Thank you for putting this together.

shmerl 2mo ago

> A lot of people still use X11 over Wayland because Wayland is said to have much worse input lag Wayland is fine. People should use AMD and KDE Plasma. I'd avoid Nvidia to begin with.

bigyabai 2mo ago
AMD's Mesa drivers are better, but if you already have an Nvidia card then you can still use it just fine with Wayland. The biggest hit is Vulkan performance (~20% less than Windows iirc) but for desktop and casual gaming use, Nvidia's proprietary drivers are perfectly fine.
- tfrancisl 2mo ago
  Seconding this. I'm not happy with the fact that the drivers are proprietary, I really prefer FOSS. But, I am tired of having to deal with FUD around performance and issues with NVIDIA devices which simply don't exist at scale. I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.
  - im3w1l 2mo ago
    Firefox is software rendered on linux-nvidia which leads to a bizarre situation of simple web animations lagging on decent computers.
  - shmerl 2mo ago
    I'd say it's deserved, not FUD. Nvidia did improve in some ways, but it's still way too heavy into blob even in case you plan to use it in the future with nvk. Nouveau / nova developers explained that Nvidia pushed a lot more into their firmware than AMD, turning the kernel driver into more of a shim than an actual driver. That's already a big downside.
    - bigyabai 2mo ago
      It's a tradeoff, and if you're not doing any fancy-pants CUDA work then it's a pretty big one. But most people are already using these blob-heavy drivers on Windows, so switching that same system to Linux is not a huge downgrade in terms of usability or stability. It isn't recommended for new Linux PCs, but it's not a dealbreaker for people switching OSes (anymore).

PcChip 2mo ago

I saw a very similar post a month or two ago, is this the same author? edit: no, this is the one I was remembering: https://farnoy.dev/posts/linux-latency https://farnoy.dev/posts/linux-latency

stusmall 2mo ago

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.

esseph 2mo ago

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.

prhn 2mo ago

Awesome article. 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.

marinhero 2mo ago
I moved to OpenSuse and have the same experience/opinion. The only caveat I had in Wayland is Game Streaming. Sunshine/Moonlight work but the input lag is noticeable and there are artifacts in the game. I go back and forth between X11 and Wayland just because X11 better for game streaming but in time I'm sure I'll go full-time into Wayland.
- wing-_-nuts 2mo ago
  When you say game streaming, is this the steam streaming stack?
  - _kidlike 2mo ago
    sunshine + moonlight is the streaming stack. Steam's one is pretty bad, and still only works in X11.
- _kidlike 2mo ago
  I've set up sunshine + moonlight on Fedora KDE Wayland, and I've played remotely from a different country with unnoticeable input lag (using a gamepad, playing Cyberpunk). The whole thing is even behind WireGuard. I have very fast internet on both sides, both fiber to the home, with only the tablet running moonlight being on WiFi.

seba_dos1 2mo ago

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.

markasoftware 2mo ago
Yep, OP should certainly retest under gnome. Im not in the weeds myself but I get the vibe that gnome's wayland compositor is somewhat faster and more carefully designed than kwin (at least, Emacs in pgtk mode does substantially better under gnome, whereas on Kwin it uses substantial cpu when scrolling and even lags a bit at high resolutions)
School-Cotton 2mo ago
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! User: But X was working fine...
- seba_dos1 2mo ago
  Is this some kind of Pavlov's dog reaction? That's not what my comment was about, and even if it was it wouldn't make any sense anyway as KWin had good results in these measurements.
  - cwillu 2mo ago
    It's exactly what your comment was about: the same boring motte and bailey fallacy of “you don't understand, wayland is a protocol” If your protocol you pushed to replace a working implementation invites a dozen poor implementations which people routinely confuse, that's a problem with the protocol and the push to get people to use it.

modeless 2mo ago

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!

NelsonMinar 2mo ago

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.

mikepurvis 2mo ago
I think it depends who it is making noise. There are some famous Oculus-era stories about John Carmack tracing display latency issues and then writing lengthy screeds to Samsung engineers to get them to give him lower level access. I bet if someone like him made enough noise, people at MS would pay attention.
- cwillu 2mo ago
  Sure, but isn't that the point? Needing to be a celebrity to fix something?
torginus 2mo ago
This kind of thing is certainly possible under Windows - you can basically patch any kernel API call, replace any COM object instantiation, install filter drivers that intercept any request to and from a device, replace userland DLLs with your own. It's really scary what you can do, to the point that I often asked myself 'why allow this?' - seeing as hits on certain APIs took me to blackhat forums and articles about writing exploits.
- pbhjpbhj 2mo ago
  Oh sure, but if I just need to troubleshoot why Minecraft-launcher (a first party app) won't launch ... it didn't give any output; it didn't even exist apparently, but only because MS were hiding it, had to crack out Process Explorer just to get something to troubleshoot on ... then it turns out the "turnkey" app from their first-party app store, loading the first-party app, on the same company's OS just failed with no indications to the user at all, not even a "this app crashed". Solution was to cut out as much of MS as possible ... it's just infuriating when it doesn't work, which seems to be all-the-time. More power to Bazzite and Valve, the sooner games app run in other OS the better.

calvinmorrison 2mo ago

X11 is a protocol. Xorg is an end of life'd project run by the Wayland team. Xlibre is an actively developed and maintained X11 protocol display server. Xfree86 is dead, long live Xorg. Xorg is dead, long live Xlibre!

anthk 2mo ago
Xenocara does it better than XLibre.
preisschild 2mo ago
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 https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrbSuC3d391VyReM4Wb0+JYXXA@mail.gmail.com/ https://lore.kernel.org/ksummit/CAHk-=wiB6FJknDC5PMfpkg4gZrb... Would you run and rely on TempleOS? Then XLibre is for you!
- calvinmorrison 2mo ago
  He didn't break Xorg because xorg isn't shipping new releases. All developers introduce bugs.
- tempaccountabgd 2mo ago
  [dead]

dreamlayers 2mo ago

Why isn't Wayland better than X11?

inigyou 2mo ago
[flagged]
seba_dos1 2mo ago
Because when it's done right it's not the compositor/display server that's the bottleneck.
preisschild 2mo ago
Could just be because of the proprietary nvidia driver or its specific to KDE's wayland compositor. We'd need more data.

hs86 2mo ago

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?

wao0uuno 2mo ago
[dead]
Cieric 2mo ago
As someone who is in the rendering space for work. Having a higher framerate does help, but in a weird way. Basically the start of the frame rendering is what mostly dictates where objects are rendered. By getting a higher framerate the position of objects that you see in game are much closer to their "real" position. So it's less about seeing more frames at that point and more about seeing the most up to date information possible. Technically it could be possible to render the frame in sync with the framerate and just offset the rendering so it finishes right before it's pushed to the screen, but if you're slightly wrong you'll get really bad stuttering and the execution time of gpus and the cpu submitting the work isn't really deterministic.
- colechristensen 2mo ago
  As the frame rate goes up the lag between the game state and display state goes down. It doesn't matter that the "extra" frames aren't displayed, the frame that is being displayed needs to be as up to date as possible.
  - Cieric 2mo ago
    Yes, thanks for saying it more concisely/clearly than I did. Just cause I understand something doesn't mean I'm good at explaining it.

bsimpson 2mo ago

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: - https://pascal.giard.info/techreports/nguyen-daniel-autocalib-fender-mustang-pro.pdf https://pascal.giard.info/techreports/nguyen-daniel-autocali... - https://www.niangames.com/articles/reverse-engineering-rockband-guitar-controllers https://www.niangames.com/articles/reverse-engineering-rockb... - https://github.com/torvalds/linux/blob/master/drivers/hid/hid-sony.c https://github.com/torvalds/linux/blob/master/drivers/hid/hi...

Telaneo 2mo ago

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.

haunter 2mo ago

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

AlienRobot 2mo ago
I'm not sure I understand. If X11 software requires a X11 server and you have a Wayland compositor, how do you "avoid" XWayland?
upboundspiral 2mo ago
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...
- seba_dos1 2mo ago
  What you're saying doesn't make any sense. Gamescope is essentially a XWayland-only compositor (with some basic xdg-shell support that's disabled by default). All games on SteamOS go through XWayland. It doesn't yet mean that it suffers from the latency measured in the article, as the problem could very well be in something else, such as how KWin integrates with XWayland or how GPU drivers interact with it (especially that Nvidia drivers have a history of making XWayland suffer).
- bionade24 2mo ago
  gamescope absolutely can have Xwayland child panes & this is currently the default on SteamOS running games with Proton, unless PROTON_ENABLE_WAYLAND=1 is set in the game options.
wao0uuno 2mo ago
Whole 3.13ms? Man idk shit’s unplayable now. 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.

clodecloud 2mo ago

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

Havoc 2mo ago

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.

bee_rider 2mo ago
That’s interesting. Hyprland, spartan? It’s the fancy everything-and-the-kitchen-sink tiling WM, isn’t it?
- Havoc 2mo ago
  Spartan...haha...I mean it's all relative. Certain relative to the other two boxes I use daily - macos & win. I do know it is favoured by ricers with animations & transparency but I just use it to tile stuff. Think I selected it over sway & i3 due to wayland support at the time. Not sure.
inigyou 2mo ago
I guess you'd feel the same in i3 or Xmonad as well.

Aurornis 2mo ago

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.

boomskats 2mo ago

A lot of people conflate Wayland being worse than X11 with Gnome on Wayland being worse than Gnome on X11. Wayland has been great for me for a few years now. I don't use Gnome or nvidia though.

doubled112 2mo ago
If I understand the semantics of it all correctly, in that sense, there is no such thing as "Wayland". It is all a little bit confusing compared to the X11 ecosystem. You don't run GNOME on Wayland. You run GNOME's Wayland compositor, which is an entirely different implementation than Plasma's Wayland compositor.
- boomskats 2mo ago
  That's what I mean though. I've not used gnome for years, but I have a vague memory of gnome/mutter running on a single main thread which used to lock up quite a lot (javascript etc). And because in X it was X that used to manage things like rendering the mouse pointer every frame, whereas in Wayland it flipped to mutter having to do it directly, the stalls were way more obvious in wayland than X, which is where I think a lot of this perception came from. Again, not sure how much of this is accurate, but that's the point I was trying to make.
  - seba_dos1 2mo ago
    Yeah, I believe Mutter is directly responsible for a lot of bad rep Wayland gets. It got better in many areas, but the damage is done.

torginus 2mo ago

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.

feverzsj 2mo ago

Yes, we know wayland is not only slower but also with much less features.

gfxfan 2mo ago

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.

xyst 2mo ago

Very interesting analysis and setup. 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

hoechst 2mo ago
Hi, OP here. I just made sure no other user space application were running. Something that basically can be reasonable expected by a person that cares about game performance to do. For example, no one would stop sshd before their gaming session, but closing a Browser is reasonable imo. That said, this is a pure gaming PC with a Desktop Linux installed, it's not like there's a lot running on there in the first place: no 5 random docker containers, no AppArmor and nothing in kernel space other than what comes by default with CachyOS.

ElijahLynn 2mo ago

Wow, love this!! This is what makes HN great!

Benjamin_Dobell 2mo ago

Been dealing with this a bit at Breaka Club. We teach kids to code with a modded version of Overcooked 2!. We stream OC2[1] with our mod preinstalled over WebRTC. This ensures that kids/schools don't have to try and install the mod. This is particularly important since we support running on school provided hardware. Installing a game without a mod would be hard enough. Added advantage though is kids play with a virtual (on screen) gamepad on iPads in Mobile Safari. Game instances run in Docker containers in Kubernetes/k3s atop very outdated nVidia hardware. Given we're already going across the Internet into school networks, we've tried very hard to optimize latency across the board. Using NVidia NVEnc with DMABuf (zero copy) etc. We're unfortunately using XWayland at present so experience the documented input overhead. Although our inputs are virtual devices at this point, so the overhead may be a bit different. Trying to optimize this whole thing end to end has been a challenge. I would say that performance is currently "acceptable". OC2 coding: https://www.youtube.com/watch?v=ITWSL5lTLig https://www.youtube.com/watch?v=ITWSL5lTLig (not streamed in this case) [1] We've bought a limited number of copies of OC2 and pods claim a license on startup. If we're at capacity, kids play something else.

eaf7e281 2mo ago

Really hope to see a Windows result. What if Windows has a latency of 10 ms+. xD

closeneough 2mo ago

How does Windows compare to this?

teodorlu 2mo ago

Very interesting! Latency numbers are written with three significant digits (4.21 ms). I'm curious about the accuracy of the measurement device. If it can measure tens of microseconds, I'm impressed. If it can't, the conclusions in this article should be taken more coarsely.

zaik 2mo ago
> it starts collecting samples from the photodiode (every ~24 µs). They also have repeated measurements which improves the precision.
ant6n 2mo ago
For 300 tests, it seems reasonable to report with some more precision on the median.

DarkmSparks 2mo ago

The main issue is with mouse movement rather than clicks tho...

Night_Thastus 2mo ago
Clicks and mouse movement do have different latency, but it doesn't matter for this test. The click is the constant part to show relative positioning of X11/wayland/low latency/vrr/etc. The relative performance should be the same ranking for mouse movement, just with different exact values.
- DarkmSparks 2mo ago
  Different order of magnitude in my experience. Wayland mouse movement lag is/can be/could/was in the order of several hundred milliseconds. Its that that people notice, not 3 or 4ms difference in click response.

criddell 2mo ago

These results are way better than what Dan Luu measured almost a decade ago: https://danluu.com/input-lag/ https://danluu.com/input-lag/ Even if everything else is perfect, display latency on modern panels is 1-3 ms. So all of the input processing and display pipeline can't be taking more than a millisecond or two and that's remarkable.

throwaway270925 2mo ago
Well thats also partly because they use a 500hz display in tfa. An update to Dan Luus articles with modern tech like these high refresh displays, fast gamer keyboards/mice etc would be great thought!

saltcured 2mo ago

The input latency that has been driving me crazy lately is the screen unblank latency to allow input to a program. E.g. I have an old laptop running a browser playing some internet radio stream. Eventually the screen blanker (without locking) activates. Some real life event makes me want to hit the space bar to pause music. But the modern screen blank has decided that it should eat/ignore key presses while blank. So hitting the key doesn't pause music. I have to wait for the screen to light up before it will be possible to trigger the pause, and this delay feels interminable! I seem to recall that in the old days the input remained active to the focused window even if the screen was in a power saving state. This power saving was not conflated with screen-lock security etc. I much prefer that. I think this was because DPMS power saving was an underlying X server behavior, not delegated to a screensaver/lock application? I'd also be partially satisfied with the async behavior of old terminal programs. My inputs should be buffered and processed even if the effects haven't returned to the screen yet. Then I could at least hit keys twice and be trained to know that one would unblank, the other would pause, and all would be well (eventually). The current behavior is like having a temporarily numb hand, and being frustrated waiting for sensation to return before I can operate anything!

wing-_-nuts 2mo ago
Question, does your monitor have a KVM? Cause I definitely notice this behavior, even on windows and os x with my monitor. I believe it was the same way on linux as well but it's been a minute since I used linux on my desktop
- saltcured 2mo ago
  This is actually a laptop with its builtin display. Edit to add: I don't think it has too much to do with display latency. It is some convolution of the desktop environment and display server deciding that keyboard input doesn't go to the focused window while it is in this nominal screen blank state. This Fedora 43 on a boring generic Thinkpad.

inigyou 2mo ago

This website uses IP address blocking to censor itself, and deserves to be publicly shamed for it. Here's an archive link: https://archive.is/hrYZ6 https://archive.is/hrYZ6

hoechst 2mo ago
Hello, this is my website and I do not know what you mean by this. If you give me technical details (like the subnet your operating out of), I can take a look at it. My webserver is using crowdsec (https://www.crowdsec.net https://www.crowdsec.net) to ban malicious IPs and I would guess that you are somehow unintentionally affected by this. You can also test your IP by entering it into the crowdsec website to see if it is affected.
- inigyou 2mo ago
  There you go then. Thank you for confirming my determination of IP blocking. The archive link above may work for the users you censor. Paying $1900/month for an IP address blocklist for a website? Yikes.
  - hoechst 2mo ago
    Yes, I am determined to shield my servers from malicious actors and bots that attempt to exploit it. This sometimes can lead to false positives and I am willing and cooperative in rectifying this to allow open access to real people that want to access the services I provide and make sure stuff like this won't happen again. The security and availability of my servers is as important to me as the ability for anyone to access the public services I provide. Which is why I responded to you immediately and asked for your cooperation to help me fix the problem. You not being cooperative helps no one. Not yourself, not other people with the same issue and not me who's trying to fix it. Crowdsec is free btw, I do not pay anything.
    - inigyou 2mo ago
      The most secure shield is to drop 0.0.0.0/0. IP addresses can't be malicious - they are just numbers.

sellmesoap 2mo ago

I appreciate the article, it's cool to see such small differences across all those settings! It says they learned to solder, if you see solder joins that look like those in the first picture, keep learning! Those are some dry joins, which can easily lead to failure, or intermittant signal loss. Soldering can be a touchy sport!

hoechst 2mo ago
OP here, thank you for the feedback. I will keep it in mind for the next time I'm soldering something.
- sellmesoap 2mo ago
  The main trick is getting the pad/component hot enough that you're adding solder to them, not to the iron. The end result should look like the solder is a smooth fillet, not jaggy/crystalized bumps. Now to tweak my nixos gaming rig with your settings thanks to your research!

coldblues 2mo ago

Addressing all the people here talking about latency of under 10ms, I direct you towards these: https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=fE-P_7-YiVM https://www.youtube.com/watch?v=fE-P_7-YiVM https://news.ycombinator.com/item?id=42832155 https://news.ycombinator.com/item?id=42832155

delusional 2mo ago

Hey, I made one of these too[1]. One of the cool things about my implementation is that the sample loop is carefully written in cycle counted assembly to sample the ADC of the teensy 2.0 at the absolute maximum frequency. I like your blogpost a lot more than mine though. [1] Github: https://github.com/DelusionalLogic/Frametime https://github.com/DelusionalLogic/Frametime, Blogpost: https://www.jnsn.dev/posts/frametime/ https://www.jnsn.dev/posts/frametime/, and followup: https://www.jnsn.dev/posts/fastisslow/ https://www.jnsn.dev/posts/fastisslow/

hoechst 2mo ago
That's awesome, odd that I did not come across your project when i was researching this. I'll make sure to read your posts and source code.

abc42 2mo ago

Huh. I turned on PROTON_ENABLE_WAYLAND=1 when it became available and didn't notice any change in input lag. Probably one of the many reasons why I'm not a competitive player. I also don't like to play above 60Hz.

maltelau 2mo ago
At 60 Hz, there are 16.6 ms between frames, so the ~3 ms improvement from not using XWayland would be very hard to notice visually. Where it can make a difference is that some competitive FPS games have some kind of client side hitscan or lag compensation and often play at high refresh rates, so there it can actually matter that their system reports to the multiplayer server that you clicked in the right place a couple of milliseconds earlier.
- abc42 2mo ago
  Oh, cool! Thanks for the knowledge.
account42 2mo ago
> I also don't like to play above 60Hz. But why?
- abc42 2mo ago
  Wrong framing. I would need a reason to go above 60Hz, since it doesn't look any better to me and just wastes energy.
  - mfro 2mo ago
    Are you sure you've ever gone above 60hz and 60fps? It is unequivocally agreed to look much better
    - abc42 2mo ago
      I am. It's meh. People like different things.

heyyyshiv 2mo ago

great

somehnguy 2mo ago

Well written article with a lot of interesting info. I do wish there was a comparison to Windows as well though, as a frame of reference.

url00 2mo ago

Something interesting is the author right away wants to isolate and reduce placebo. But surely, latency is all about "placebo" and "vibes" and "feel" is it not? The ultimate test is how it feels to use on a personal level. Of course, where gathering this sort of data _is_ useful is diagnosing and fixing real latency so it obviously has merit. I just think it's ok to lean on taste and experience for most things UI/UX, including latency. Another point, by couching the comparison in a less technical form (for example, rating a configuration/setup out of 5 stars or some similar approach), it protects from being "too methodological" during testing and data-gathering. One possible issue with the author's methods is if there are degenerative cases that are common in the day-to-day experience of a given configuration, they are unlikely to be present during the precise test that they have setup.

httpsterio 2mo ago
Can't say that I agree. I play rhythm games on a national level and benchmarking and reducing input latency is very important in those games. The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell. Vibes and latency don't belong in the same sentence at all imo.
- cwillu 2mo ago
  It's vibes when you don't have the tools to isolate and measure it. It's unfortunate that “vibe” is almost always pejorative these days.
noAnswer 2mo ago
> But surely, latency is all about "placebo" and "vibes" and "feel" is it not? Not sure if I can follow but...no?! My first TFT-TV had 2 seconds input lag. Impossible to play video games on it. That has nothing to do with feelings. Already 10ms delay has a measurable effect: https://www.youtube.com/watch?v=5qjSGEOEaXo https://www.youtube.com/watch?v=5qjSGEOEaXo
tverbeure 2mo ago

__mharrison__ 2mo ago

I need to look into this more. I was trying to vibe code an OBS plug-in just last week to measure sync between audio and video. My system flashed the screen white and played a note. The idea was to have the camera detect monitor brightness and detect the offset from the audio note. I'm practice the brightness of a 40 inch TV didn't seem to impact the video of the insta 360 link webcam. (I ended up vibe coding a Python GUI to quickly allow me to push through video frames and show the audio frequency. I could quickly type 'v' (video) where I clapped and 'a' (audio) where the waveform changed. It would then tell me the offset...

YmiYugy 2mo ago

Seeing a comparison of different Wayland compositors could be very interesting.

tokyovigilante 2mo ago

This is great but it would be even better if 60Hz results were also presented.

casey2 2mo ago

The article stops halfway through. For developers to do serious work fixing the flaws of wayland they need to know what is causing those hiccups that some users are getting. Not just run wayland on a 500hz monitor and say #NOT_A_PROBLEM #WONTFIX

kelvinjps10 2mo ago

Aren't most games in XWayland? so it means that basically most games run way slower in Wayland.

snarfy 2mo ago

A friend commented that since the sensor is not center vertically on the monitor, VRR will win by default.

3abiton 2mo ago

This was a very enjoyable read, and loved the distribution inclusion, rather than point statistics. I hope there are more tests on different factors like GPUs (nvidia vs amd vs intel), screens, mice, and ultimately windows to see if there is really a difference. I don't play competitve gaming, but careful data driven approach would put a lot of the debated questions to rest.

eqvinox 2mo ago

> So, does X11 have lower latency than Wayland? > Yes, but nowhere near enough to explain why Wayland is generally perceived as much worse than X11. Personally speaking: Wayland has massive stutters when the system is under load, most notably on the mouse pointer. X11 doesn't.

cl3misch 2mo ago

This hits a very soft spot for me. My beloved Spelunky 2 has huge input lag "on Linux", which makes it unplayable for me. It's pretty much the reason I keep my Windows 10 install around. I could not come up with a configuration on Linux that avoids the lag. It's extra infuriating that online sources report the game running flawlessly but seem to ignore input lag.

cl3misch 2mo ago
Inspired by my own comment I looked into it again and came up with this combination in the game's "launch options", which feels much better: DXVK_CONFIG="dxgi.syncInterval = 0; dxgi.maxFrameLatency = 1; dxgi.maxFrameRate = 60" gamescope -f --immediate-flips -- %command% I didn't know about `DXVK_CONFIG` before. It's the DirectX-Vulkan translation layer with its own framebuffer and latency. I also manually disabled vsync in the game's `local.cfg` XML file. I love where "gaming on Linux" is going. But I have the feeling the hype on Youtube etc. is in part created by content creators, and doesn't faithfully represent the actual situation (surprise!).

billev2k 2mo ago

Contrast is your friend. Or at least mine.

throwaway270925 2mo ago
Open the menu and click the paint bucket. It seems to cycle through color themes :)

tsoukase 2mo ago

With so low differences one should always use VRR and not bother about the rest config. Sub-ms differences are impossible to detect.

MobiusHorizons 2mo ago

Interesting analysis! It would be very interesting to see how this compares to windows on the same hardware.