I built a device to measure end-to-end input latency, then used it to find out what actually moves the needle.
  • Björn@swg-empire.deEnglish
    17·
    1 day ago

    Avoid XWayland

    It added 3.13 ms of latency, more than all other effects combined. Wayland is close, but X11 still wins

    Though only by 0.14 to 0.22 ms. Given there are efforts to optimize KWin, this gap will likely close sooner rather than later. And who knows, other Wayland compositors might already be better. VRR has the biggest effect

    VRR was faster in every pairing (0.26 to 0.45 ms) and also flattened the latency distribution. dxvk-low-latency is a win across the board

    0.10 to 0.29 ms in capped scenarios is a nice boost, but the real strength of the fork shows in the uncapped test case, where it gained 0.84 ms over default dxvk.

    Additionally, in scenarios where XWayland can’t be avoided, it recovered a full 2.1 ms. Conclusion

    Not factoring in XWayland, applying every optimization (X11, VRR, low-latency) compared to a default setup (which, on a modern Linux system, I assume is plain Wayland) moved the median down by 0.72 ms.

    That does not sound like a lot, but the raw latency does not tell the whole story as VRR additionally reduces latency jitter, and dxvk-low-latency’s pacer is great at smoothing out real-world scenarios where frame time dips and GPU-bound situations occur.

    • sp3ctr4l@lemmy.dbzer0.comEnglish
      3·
      1 day ago

      So I skimmed the actual article, not sure if the author said this, but my guess as to why Wayland has a … worse reputation generally in the latency department, than seems to be deserved?

      At least for myself, there was a significant period of time where … XWayland was the only way to actually run whatever game, on my system, with/via Wayland.

      If this kind of thing was not just myself, and was generally common… well then XWayland = Wayland -> Wayland sucks.