Live data from Hacker News

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

marco-nett.de

201–210 of 297 posts

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

#201
post #174

Earlier quoted context omitted.

It's generally a single checkbox to turn off compositing in X11, for precisely this reason.

You can also disable compositing conditionally in KDE, such as when a game window is opened.

Not in Wayland, the whole point of Wayland is to make stuff the X server + compositor + various other bits into the window manager.

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

#202
post #64

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

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.

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

#203
post #75

Earlier quoted context omitted.

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 o…

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.

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

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

#204

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…

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

My experience has been reasonably consistent. My main DE is KDE, it switches between light and dark based on my location and time. It switches to warmer colors at night. I have never had a problem in the applications I use. I occasionally switch on the fancy effects like windows fall apart when I'm in the fun mode, or I'm showing something to friends, as a bit of fun makes everything more interesting, and all work perfectly well.

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

#205

Earlier quoted context omitted.

With the exception of XWayland, all of the tests had input latencies within a very small range. No human could tell them apart by those latency differences alone. I would be amazed if someone could notice the 3ms difference jump to XWayland. The difference could be much larger on a slower monitor. However the differences between Wayland and X11 as protocols is negligible. XWayland as an implementation looks to have a…

I can tell down to about a 3ms difference in lag. Actually even down to 1ms, it's not all its cracked up to be, lemme tell you.

You think you can and will inevitably fail to do it in blind testing.

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

#206
post #13

Earlier quoted context omitted.

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.

Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal: - Effort spent writing sway that could have been spent improving i3 - Effort spent wr…

The 'small number of developers' who no longer wish to maintain X and have moved on shouldn't be blamed.

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

#208

Earlier quoted context omitted.

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.

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…

The most secure shield is to drop 0.0.0.0/0. IP addresses can't be malicious - they are just numbers.

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

#210

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! User: But X was working fine...

It is a weird argument because X11 is also just a protocol. Sure at this point there is only really one server left in the wild(xorg). But historically there have been more.

And on that topic a question I have, seeing as wayland is "just a protocol" why can't the client application talk to the compositor server over a network socket instead of a unix domain socket? Update: reading the spec I found my answer, Wayland buffers are shared memory surfaces... So really wayland is not "just a protocol"

Post reply on HN