Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marco-nett.de

Post reply on HN
Print view View original

171–180 of 297 posts

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

#171

Post by ofalkaed »

Aurornis wrote: post #40
prhn wrote: post #11

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…

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 have no idea about gaming but in the music world you start noticing latency when it is above 5ms and the difference between 5 and 8ms is tangible. For the most part anything under 10ms is workable and you will quickly adapt as long as the latency is constant. Under 10ms of latency is a level of latency we are used to dealing with, if you are playing guitar and your amp is 10 feet from you, you have ~9ms of latency. Our brains are pretty good at adapting to these short latencies as long as they are predictable.

The visual latency on gaming could be different but I suspect not, I think it is more an issue that some people fixate on the latency, others just accept and adapt to it. Games do have more possible sources of latency, visual, audio and io, and if these can all be different that can be difficult; years ago I had an issue with this and midi, that one really threw me off. Games may also not model the physics of sound? does sound travel slower than light in games? That could worsen the problem since sound does travel slower in real life and we are used to that, we expect it.

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

#172

Post by Telaneo »

drdexebtjl wrote: post #163
Telaneo wrote: post #80

Earlier quoted context omitted.

A fair argument at least for some games. The games I have in mind though still have those details present on lower settings. Instead they just look like shit rather than disappear. To be fair though, that just might make those details have higher contrast and not fade into the background as much.

Yeah. I think there are so many hypotheses we could test if professional players were willing to do these experiments. For example, it used to be popular among competitive CS players to use 4:3 resolutions on 16:9 monitors. Since the target’s vertical position is much more predictable than its horizontal position, it’s supposedly easier to aim if the image is stretched wide. But these games only presented 4:3 options…

It's become less common to play in 4:3 over the years. The additional peripheral vision has become too obvious a benefit to not make use of.

It's probably mostly a habit thing. Most of the pros started to play these games back in the 90s, when 4:3 was the standard. Add in that playing all the low resolution options are 4:3 (and the 16:9 equivalents will add resolutions rather than take it away; the 1080p is usually 16:9, so 1920x1080, but 4:3 1080p does exist, and it's 1440x1080, which is a lower resolution), it's no wonder 4:3 stuck around as long as it did.

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

#173

Post by cwillu »

uecker wrote: post #130
wing-_-nuts wrote: post #81

Earlier quoted context omitted.

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

And all the gaslighting. Using X forward basically every day but being told it is useless and broken and nobody needs it...

And don't forget the “this isn't a wayland problem” whenever a major missing feature provided by the X11 ecosystem is mentioned. Guess what: if you're going to replace the whole ecosystem, you're responsible for all the missing things regardless of your opinions of the matter.

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

#174

Post by cwillu »

gf000 wrote: post #138
hackernudes wrote: post #61

Earlier quoted context omitted.

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

And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.

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

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

#175

Post by cwillu »

seba_dos1 wrote: post #125
School-Cotton wrote: post #104

Earlier quoted context omitted.

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

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.

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.

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

#176

Post by yxhuvud »

wing-_-nuts wrote: post #81
datakan wrote: 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.

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

Forced on who, by who? It is the DE/WM people that is driving the thing.

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

#177

Post by FeepingCreature »

datakan wrote: post #13
cgyvbunji wrote: post #3

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.

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.

try to share your screen on a native tool older than a few years lol

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

#178

Post by FeepingCreature »

cwillu wrote: post #174
gf000 wrote: post #138

Earlier quoted context omitted.

And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.

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.

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

#179

Post by Aardwolf »

NelsonMinar wrote: post #15

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.

Today they have all these layers of abstraction for themes, icon sets and light and dark mode and what not, but almost NO combination works!

If you set light mode, you'll get some light gray text on lighter gray background somewhere, but if you use dark mode, then you'll get some black text rendered on a black background elsewhere. And even if not involving light or dark mode, same misery with whatever themes like "Adwaita" and others, some things will work in one, other things in another, I've seen a PDF viewer that made everything black text on black background in some desktop themes... A PDF viewer can't even independently choose its own text and background color without the desktop environment messing with it?

No theme I found anywhere has _well visible_ scrollbars, they all seem to love making them as subtle as possible so you can hardly see where your scroll position actually is. No theme I found anywhere has a _clear visual distinction_ (different color, not just a subtle shade difference) for the selected window vs the non selected ones. This would be _extremely_ handy for knowing in what window you're typing now, even windows 3.11 got this (and the scrollbars, and the ability to customize your colors) better

While not latency, it's still a thing they just can't get right, and when things were less overdesigned it actually worked better, so what was all this for?

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

#180

Post by 9029 »

seba_dos1 wrote: post #12

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.

Another post suspects Nvidia drivers: https://davidjusto.com/articles/m2p-latency/#results
Post reply on HN