Live data from Hacker News

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

marco-nett.de

281–290 of 297 posts

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

#281

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

Desktop environments have improved so many times over IMO. KDE and Gnome are legitimately high-performance and extremely usable - more so than Windows or Mac in my experience.

Yes theming in particular has gotten complex, but that's largely because of the application domain. We now abuse electron for everything. And, if it's any consolation, it's still 100x better than Windows, which can't decide on less than 12 themes for its own built-in applications, let alone third-party apps.

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

#282
post #174
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.

Yes, but the same is true in Wayland and it's automatic as well. Full screen applications don't require compositing so they typically don't, and this was the case in MOST X11 compositors as well.

Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.

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

#283

Earlier quoted context omitted.

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

It is absolutely not the DE/WM devs driving this, it's the wayland folks saying that xorg would no longer be maintained. They literally just dumped an Ikea box of protocols on the table without even bothering to provide a decent sample implementation and said 'good luck!'

1. There is/was a sample implementation.

2. There are currently many high-quality implementations, Kwin being the best IMO.

3. X11 devs didn't want to maintain it, nobody "made them" stop. You or I could maintain it, but I also don't want to, so, here we are.

4. Yeah the wayland transition was rough but I think there's basically no universe where that transition would be perfect. They're architecturally different things. The Apple Intel to M series transition wasn't perfect either and there were A LOT of bugs. These things just happen.

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

#284

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!

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-=wiB6FJknDC5PMfpkg4gZrb... Would you run and rely on TempleOS? Then XLibre is for you!

[dead]

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

#285

Earlier quoted context omitted.

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

> Its their time to spend as they see fit.

I'm complaining on these developers' behalf, not bemoaning them doing what they were more or less forced to do. If glibc decided tomorrow to remove the `malloc` function from their library and every C project suddenly had to implement its own allocator, that would be a massive waste of everybody's time, no?

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

#286
post #277

Earlier quoted context omitted.

> I also don't like to play above 60Hz. But why?

Wrong framing. I would need a reason to go above 60Hz, since it doesn't look any better to me and just wastes energy.

Are you sure you've ever gone above 60hz and 60fps? It is unequivocally agreed to look much better

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

#287
post #174

Earlier quoted context omitted.

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

Yes, but the same is true in Wayland and it's automatic as well. Full screen applications don't require compositing so they typically don't, and this was the case in MOST X11 compositors as well. Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.

> latency should be identical

Should be, but very clearly isn't.

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

#288

Earlier quoted context omitted.

mostly i'm trying to get out of the terminal and most IDEs don't understand devbox/distrobox well without lots of finagling.

I install the IDE as well as tools inside distrobox.

don't you then have to keep your IDE config synced across them an open a whole instance for each project? Why even have an OS underneath it at this point?

Sometimes it feels like I'm just being asked to install a real linux distro inside my linux distro so I can actually do things. Here's you nice shiny desktop and app store! Oh you want to do more than browse the web? Better install linux again in a VM.

Maybe i'm just stuck in legacy paradigms, but I kind of like just booting IntelliJ and picking the project i'm on today.

Or sometimes I want to move stuff between projects i'm working on, that's a lot easier if my one IDE instance can hit them all at the same time.

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

#289
post #287

Earlier quoted context omitted.

Yes, but the same is true in Wayland and it's automatic as well. Full screen applications don't require compositing so they typically don't, and this was the case in MOST X11 compositors as well. Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.

> latency should be identical Should be, but very clearly isn't.

The results show it's identical. Only XWayland suffered any significant degradation, and even then we're talking <5ms which is imperceptible.
Post reply on HN