Live data from Hacker News

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

marco-nett.de

251–260 of 297 posts

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

#251

Earlier quoted context omitted.

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.

By the time wayland becomes the default in xfce, maybe the wayland team will have added window positioning to the protocol...

Never going to happen but maybe we'll get a couple incompatible DE-specific extensions.

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

#252

Earlier quoted context omitted.

While reaction response is around 100ms, for predictive movements, ie press a button exactly when a bouncing ball hits the ground, average people can get down into 5-7ms of timing accuracy[1]. Trained people can get below 4ms in certain cases. Of course, the brain adapts. I played an online shooter at >100 FPS using my 144 Hz monitor (when that was the best). I visited a buddy who's PC could only muster 30-40 FPS, an…

Well, of course people can generally see the difference between 30 and 100+ FPS but it is much bigger delay than 1ms OP claimed they can distinguish.

As noted in the paper I linked to, display framerate did not affect the timing precision of their participants, from 120Hz down to 24Hz. So it's more about feeling it rather than seeing it.

If you can be accurate to below 5ms, an additional millisecond of input lag makes a big difference.

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

#253

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…

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

You mean the professionals being paid by Red Hat?

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

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

I use gamescope on a separate TTY that directly launches either steam or heroic launcher. I find this works exceptionally well. No window manager needed as you are playing a game full screen anyway. It fixed some other things like HDR too but at a loss of the volume and brightness keys no longer working.

That sounds very interesting, do you have any links or references on how you set it up?

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

#255
post #42

Earlier quoted context omitted.

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

Tearing can theoretically improve latency for the part of the screen that's below the tear, but in any case where you could actually benefit from it the difference would be at least order of magnitude smaller than the duration of one frame.

[deleted]

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

#256
post #210

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

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…

There is only one relevant X11 server left because the design leaves policy and even compositing decisions extensible by window managers. This separation does not exist in the design of Wayland which leaves people who ant different behavior to also re-implement all the other parts, often badly.

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

#257
post #26
post #22

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

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

Delayed rendering start + VRR is the holy grail. Then small misses don't matter that much.

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

#258
post #150

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.

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

Oh, cool! Thanks for the knowledge.

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

#260

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!

Post reply on HN