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

161–170 of 297 posts

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

#161

Post by wao0uuno »

haunter wrote: post #37

SteamOS and Bazzite both use Xwayland through gamescope which is the worst option as it seems https://github.com/ValveSoftware/gamescope >Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined.

Whole 3.13ms? Man idk shit’s unplayable now.

When rendering 60fps on a 60Hz display every frame takes approximately 16ms to render. Then you have to add TV latency that’a probably around 20ms unless you have a very nice OLED TV. Wireless controller latency is around 8ms I think? Then your imperfect human brain adds even more latency especially when you’re tired after work. That 3ms is not perceivable. Make that 5ms even. Nobody would be able to tell a difference in a blind test.

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

#162

Post by DarkmSparks »

Night_Thastus wrote: post #91
DarkmSparks wrote: post #88

The main issue is with mouse movement rather than clicks tho...

Clicks and mouse movement do have different latency, but it doesn't matter for this test. The click is the constant part to show relative positioning of X11/wayland/low latency/vrr/etc. The relative performance should be the same ranking for mouse movement, just with different exact values.

Different order of magnitude in my experience.

Wayland mouse movement lag is/can be/could/was in the order of several hundred milliseconds.

Its that that people notice, not 3 or 4ms difference in click response.

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

#163

Post by drdexebtjl »

Telaneo wrote: post #80
drdexebtjl wrote: post #71

Earlier quoted context omitted.

There’s an argument to be made that dropping all unimportant detail could make professional players react faster even if it doesn’t improve end-to-end latency in the PC. This is something that could be tested experimentally, but isn’t, because the subjects we would need to test this on are all sponsored by hardware vendors.

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 at low resolutions. This might have introduced the notion that low resolutions provide an advantage in general.

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

#164

Post by httpsterio »

url00 wrote: 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,…

Can't say that I agree. I play rhythm games on a national level and benchmarking and reducing input latency is very important in those games.

The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell.

Vibes and latency don't belong in the same sentence at all imo.

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

#165

Post by __mharrison__ »

I need to look into this more. I was trying to vibe code an OBS plug-in just last week to measure sync between audio and video.

My system flashed the screen white and played a note. The idea was to have the camera detect monitor brightness and detect the offset from the audio note. I'm practice the brightness of a 40 inch TV didn't seem to impact the video of the insta 360 link webcam.

(I ended up vibe coding a Python GUI to quickly allow me to push through video frames and show the audio frequency. I could quickly type 'v' (video) where I clapped and 'a' (audio) where the waveform changed. It would then tell me the offset...

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

#166

Post by maltelau »

abc42 wrote: 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 couple of milliseconds earlier.

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

#167

Post by noAnswer »

url00 wrote: 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?

Not sure if I can follow but...no?! My first TFT-TV had 2 seconds input lag. Impossible to play video games on it. That has nothing to do with feelings.

Already 10ms delay has a measurable effect: https://www.youtube.com/watch?v=5qjSGEOEaXo

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

#168

Post by cwillu »

mikepurvis wrote: post #35
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…

I think it depends who it is making noise. There are some famous Oculus-era stories about John Carmack tracing display latency issues and then writing lengthy screeds to Samsung engineers to get them to give him lower level access. I bet if someone like him made enough noise, people at MS would pay attention.

Sure, but isn't that the point? Needing to be a celebrity to fix something?

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

#169

Post by kev009 »

hs86 wrote: 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…

It's chronoception effect, not placebo effect. Standard literature claims humans can readily visually perceive 60-90Hz, and perhaps somewhere 500-1000Hz for ghosting. Note that all this is somewhat tangential to the article which focuses on _input latency_, I think the author is driving the high refresh just to minimize _output latency_ as much as possible from the test.

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

#170

Post by cwillu »

httpsterio wrote: post #164
url00 wrote: 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,…

Can't say that I agree. I play rhythm games on a national level and benchmarking and reducing input latency is very important in those games. The games I play (ITGmania) measure accuracy to the tenth of a millisecond, any fluctuation in your hardware latency can ruin your scores and nothing really is more annoying than an inconsistent setup where the latency change between or during a session is absolute hell. Vibes…

It's vibes when you don't have the tools to isolate and measure it. It's unfortunate that “vibe” is almost always pejorative these days.
Post reply on HN