Contrast is your friend. Or at least mine.
Open the menu and click the paint bucket. It seems to cycle through color themes :)
Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
271–280 of 297 posts
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#272Earlier quoted context omitted.
Not in Wayland, the whole point of Wayland is to make stuff the X server + compositor + various other bits into the window manager.
For full-screen applications, Wayland has a protocol to let it display frames at its own pace - meant mostly for games for this very reason.
With X11, you can disable composition for windowed apps as well.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#273Earlier quoted context omitted.
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.
That paper measures our margin of error when syncing to a perfectly predictable rhythm, not our ability to detect system latency. Applying that to an FPS doesn't really work for two reasons. First, enemies are erratic, meaning you are mostly relying on your reactive visual-motor pipeline, which is bottlenecked by ~150ms anyway. Second, even for purely predictive shots, your brain subconsciously calibrates out fixed hardware lag.
I'll concede that pure prediction absolutely exists in FPS games-like tracking a falling player with the LG in Quake 3 or landing a predictive mid-air rocket. In such cases smoothness of high FPS helps, but adding a 1ms drawing delay to those 500FPS (what the article is about) won't be noticeable at all because your brain naturally calibrates out constant hardware delay.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#274One 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…
Bazzite or CacheyOS (if you wish to do gaming and have more rope to hang yourself mainly because you can more easily affect the system if it isn’t trying to enforce immutability). TBH with the onslaught of LLM CLI’s like Claude I am a lot more promiscuous in my Linux OS choices as of late. I used to stick to Ubuntu because that was the Linux I knew, but the “interface” has become the same to me because I just ask Cla…
I stand by my comments. Bazzite has benefits being immutable but immutability can cause certain tasks to be more involved or constrained. Case in point it’s nice that Bazzite comes with a lot of sane defaults:
- brew
- podman
Here’s an example that bit me: I wanted to run k3s/k0s but both have issue with Bazzite. Those were hard stops for me.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#275Earlier quoted context omitted.
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?
Don't know about gamescope, but the core of my own wine launch script is basically this:
if [ -z "$DISPLAY" ]; then
/usr/bin/startx /usr/bin/dbus-launch "$(readlink -f $0)" "$1" -- -layout singleLayout
fi
pw-cli i || (pipewire & sleep .5 ;\
pipewire-media-session &\
pipewire-pulse &)
cd "$DIR"
exec unshare -rcn $ENGINE "$IMAGE" $ARGS
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#276Interesting analysis! It would be very interesting to see how this compares to windows on the same hardware.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#277Huh. 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.
> 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.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#278There'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.
Hi, OP here. I agree with you, "Wayland input latency" is inaccurate and I added a note to the article explaining this.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#279Earlier quoted context omitted.
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.
That paper measures our margin of error when syncing to a perfectly predictable rhythm, not our ability to detect system latency. Applying that to an FPS doesn't really work for two reasons. First, enemies are erratic, meaning you are mostly relying on your reactive visual-motor pipeline, which is bottlenecked by ~150ms anyway. Second, even for purely predictive shots, your brain subconsciously calibrates out fixed h…
It only calibrates it out over time, that was what my 100+ FPS to 30 FPS story was about.
So yes I agree over time you wouldn't be able to tell 1 ms from 2 ms, but a skilled player doing back to back comparisons might be very different.
Re: Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK
#280Earlier quoted context omitted.
That paper measures our margin of error when syncing to a perfectly predictable rhythm, not our ability to detect system latency. Applying that to an FPS doesn't really work for two reasons. First, enemies are erratic, meaning you are mostly relying on your reactive visual-motor pipeline, which is bottlenecked by ~150ms anyway. Second, even for purely predictive shots, your brain subconsciously calibrates out fixed h…
It only calibrates it out over time, that was what my 100+ FPS to 30 FPS story was about. So yes I agree over time you wouldn't be able to tell 1 ms from 2 ms, but a skilled player doing back to back comparisons might be very different.
Well, I don't think this is the case and I haven't seen any research to convince me otherwise.