Live data from Hacker News

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

marco-nett.de

191–200 of 297 posts

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

#191

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

   > 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.
I've been using Linux (Linux Mint Cinammon, then Fedora Linux GNOME) for over five years and I've never had that. What kind of desktop environment, themes and applications are you using?

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

#192
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…

How incredibly arrogant of you. Its their time to spend as they see fit. You get no say in that and complaining they didn't do what YOU wanted them to when YOU wanted them to do it is peak entitlement. Grow up

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

#193

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 , Blogpost: https://www.jnsn.dev/posts/frametime/ , and followup: https://www.jnsn.dev/post…

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.

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

#194

Earlier quoted context omitted.

I don't know enough about this to have a favorite, just know the transition was rough. Like one day at work our DE had to get changed because of whatever reasons they couldn't use X anymore, and that affected more things like Chrome Remote Desktop. Years after I tried setting up Linux on an old PC and learned that Wayland is de facto default now, but not in Mint, even though Mint is supposed to be the easy one... and…

I think Linux is about choice some folks opinions notwithstanding. It's an ecosystem where many different devs have chosen to go about the same thing many different ways. You the user then get to pick from amongst those varied and interesting choices. It however isn't about all or indeed any of those devs being obligated to support any particular choice. You can only buy a place at the table with money or sweat and m…

>Arguably the problem isn't the display server

No. If you tell users they should switch to a new display server, you shouldn't be surprised if no one takes you up on it if you don't provide basic feature parity.

If you tell DE/WM devs they should use your new protocol, but say it's now their responsibility to do all these things that the old display server did for them, don't be surprised if it doesn't get much traction.

I don't for the life of me understand why wayland took off. It's provided no benefit to the average user, or DE/WM dev, and a whole lot of hassle.

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

#195
post #157

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

> But surely, latency is all about "placebo" and "vibes" and "feel" is it not?

In the case matters most, it's not a placebo.

Imagine 2 FPS players with identical ability who play against each other. If one has a system with 4ms latency and the other has one with 5 ms latency, the former will statistically have the upper hand, even if the players can't, in isolation, notice a difference between the 2 systems.

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

#196
post #87

Earlier quoted context omitted.

This is the complete opposite of those discussions. It's taking a specific quantifiable thing and measuring it, with enough information for anyone to try and reproduce the results. It's the epitome of science, comparing it to a generic vim vs emacs flamewar which is pure subjective opinion is pretty baseless.

You can measure a 3.3ms difference, but whether someone will notice and care is a different thing.

You can feel it, too. In particular when you’re used to smoother.

It’s like going from 240Hz back to 60Hz, or even 240Hz to 120. People can tell.

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

#197
post #130

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

There is a wayland equivalent. It's called waypipe. In my experiences it often works better than x11 forwarding.

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

#198

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!

OP here, thank you for the feedback. I will keep it in mind for the next time I'm soldering something.

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

#199

Earlier quoted context omitted.

The context here is the article's author is a twitchy FPS player, those extra 3ms are something that community agonizes over. I appreciated how much effort was put into controlling the variables in this test. There's a whole lot of witchcraft associated with these kinds of efforts and he sat down and did the measurements and got real numbers. My hat is off to OP.

ping is going to dominate over 3ms in pretty much every situation. And the non-xwayland numbers are all within a single ms of each other. --- Not to undermine the measurements of the author (agree with you, it's a cool effort), but my read is that this was basically proof that it doesn't matter.

In the context of competitive online games, ping is going to be ~10-60ms, depending on your connection to the particular server you're playing on, and not particularly noisy (and that's a roundtrip time. Client-Server latency would be 5-30ms). In order for one value to "dominate over" another in an adversarial context, the variance of the former must be much greater than the base rate of the latter.

Imagine a game that's just a pistol duel. When the kerchief hits the ground, players press a button, first person to press the button wins.

In an ideal world, with no delay whatsover, the probability P(A) of player A shooting no later than player B is 100 (because both players shoot at exactly the same time). If we add 5 ms of delay to player A, then P(A) = 0 (he will always lose). If then we add 50 ms of network latency to both players, P(A) = 0 still, because 55 > 50. If we instead make that 50ms delay 50ms +- 10ms (ignoring normal distribution for the moment, pretending every value in that range is equally likely), there's a 25% chance of player A experiencing an unwinnable delay (any network delay value > 55ms results in a value greater than player B's max of 60ms), resulting in a probability of P(A) = 75% * 50* = 38%.

If we make the network delay 50ms +- 5ms, then P(A) drops to 25%.

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

#200
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…

It's their time, not for you to decide how to spend it
Post reply on HN