HN Debrief

Linux latency measurements and compositor tuning

  • Linux
  • Developer Tools
  • Hardware
  • Gaming

The post is a hands-on latency study of Linux desktop input lag. It measures keypress-to-photon timing across different compositor settings and digs into where the delay comes from, rather than blaming low FPS. The biggest findings were that compositor wakeup timing can add real latency, KDE tuning improved things, and one background app, Zed, appeared to slow down unrelated windows by keeping the compositor busy.

If desktop responsiveness matters for gaming, creative tools, or remote work, test your exact compositor, monitor, GPU, and background app mix instead of assuming Linux latency is solved. KDE Plasma came out looking like the safest default here, while niche compositors and misbehaving apps can quietly poison the whole session.

Discussion mood

Interested but frustrated. People liked the measurements and recognized the bugs, but the dominant mood was low trust that Linux desktop graphics reliably delivers low-latency behavior across compositors, GPUs, and workloads without manual tuning.

Key insights

  1. 01

    GNOME hit the same timer bug

    The millisecond wakeup issue was not a one-off quirk in this setup. A GNOME contributor said they had already fixed the same class of problem in GLib, GTK, and Mutter by moving GLib to ppoll, which gives much finer-grained wakeups. That makes the post's diagnosis more credible and shows how a tiny timer API choice can ripple all the way up to visible desktop lag.

    Audit any event-loop and timer code in latency-sensitive UI stacks. If your toolkit or compositor still rounds sleeps to milliseconds, you are leaving responsiveness on the table before you even get to rendering.

      Attribution:
    • audidude #1
  2. 02

    Modern KWin closes much of the gap

    KWin is no longer stuck with the old compositor penalty people associate with Linux desktops. Support for explicit sync, async presentation, direct scanout, and variable refresh rate means fullscreen apps can often bypass or loosen the compositor path that used to force extra waiting. That explains why KDE Plasma kept coming up as the configuration where the bad latency disappeared.

    If you need low-latency Linux graphics today, check whether your stack actually enables these features instead of judging Wayland from older behavior. Plasma is a sensible baseline because it already ships many of the right mechanisms.

      Attribution:
    • zamadatix #1
  3. 03

    Zed may keep the compositor hot

    The Zed finding likely points to a specific failure mode, not random voodoo. One commenter tied it to GPUI's history of repainting continuously instead of only on demand, which can keep KWin from ever reaching an idle present path and impose a wakeup cost on every other client. That is a much sharper explanation than "background apps are weird" and it gives a concrete reason an idle window could degrade the whole session.

    When one app seems to hurt unrelated windows, inspect whether it is continuously repainting or holding frame callbacks open. A single badly behaved client can distort the latency profile of the entire desktop.

      Attribution:
    • haeseong #1
    • jchw #1
  4. 04

    Mouse latency is the hardest one to fake

    Pointer motion got singled out as the most revealing latency metric because it is a closed feedback loop. You can type or even click partly blind, but you cannot place a cursor without seeing the system respond to each tiny movement. That makes pointer-to-display delay the test users feel most immediately, even when click or key timing looks acceptable on paper.

    Do not stop at keypress latency if you care about perceived responsiveness. Measure pointer motion too, because that is often where users notice compositor and presentation flaws first.

      Attribution:
    • eqvinox #1 #2

Against the grain

  1. 01

    Niri can be fine on VRR

    The bad niri experience did not generalize for everyone. One commenter said they had spent months running Proton in Wayland mode under niri on NVIDIA with a variable refresh rate display and had no issues. That cuts against any simple claim that niri, NVIDIA, or Wayland mode is inherently broken.

    Treat these results as configuration-specific until you reproduce them on your own hardware. Variable refresh rate, monitor timing, and app path can change the outcome enough to invalidate blanket conclusions.

      Attribution:
    • raggi #1
  2. 02

    Cross-stack weirdness is not Linux-only

    A Windows user described a GPU process crash that also knocked out the USB audio interface until reboot, despite moderate GPU and VRAM usage. The point is not that Windows is worse. It is that modern graphics, media, and I/O stacks are tangled enough on every platform that absurd cross-component failures still happen.

    Do not confuse platform polish with immunity to deep systems bugs. If your product depends on low-latency media or graphics, keep reproducible tests and recovery paths on every OS you support.

      Attribution:
    • embedding-shape #1
  3. 03

    Wayland still wins mixed-DPI monitors

    X11 defenders focused on latency and missing features, but one practical reason people stay on Wayland is that multiple monitors with different high-DPI fractional scaling settings work much better there. For many workstation setups that is not a minor edge case. It is the reason X11 stopped being tenable.

    Choose your display stack based on the failure mode that hurts your workflow most. If you run mixed-resolution multi-monitor setups, better scaling may outweigh the last bit of latency advantage from X11.

      Attribution:
    • fasterik #1

In plain english

4K ↩
A display resolution around 3840 by 2160 pixels.
AMD ↩
Advanced Micro Devices, a semiconductor company that also publishes AI software and model work.
async presentation ↩
A display mode that lets frames be shown without waiting for the compositor's normal synchronized presentation timing, which can reduce latency at the cost of tearing.
direct scanout ↩
A path where an application's frame is sent straight to the display without extra compositor compositing work.
explicit sync ↩
A graphics synchronization method where applications explicitly signal when a frame is ready for display.
FPS ↩
Frames Per Second, the rate at which new images are rendered or displayed.
GLib ↩
A low-level utility library used by GNOME and many Linux applications for event loops, data structures, and system integration.
GNOME ↩
Another major Linux desktop environment with its own window manager and graphical stack.
GPU ↩
Graphics Processing Unit, the processor that renders images and handles much of modern display output.
GPUI ↩
The custom user interface rendering framework used by the Zed editor.
GTK ↩
The GIMP Toolkit, a user interface toolkit commonly used for Linux desktop applications.
Hz ↩
Hertz, the number of times per second a display refreshes.
KDE Plasma ↩
A popular Linux desktop environment built by the KDE project.
KWin ↩
The KDE Plasma window manager and compositor that controls window drawing, effects, and display timing.
Mutter ↩
GNOME's window manager and compositor.
niri ↩
A Wayland compositor for Linux with a tiling-style interface.
NVIDIA ↩
A GPU maker whose Linux driver behavior often differs from AMD and Intel in desktop graphics stacks.
ppoll ↩
A Linux system call that waits for file descriptor events with high-resolution timing and signal handling support.
Proton ↩
Valve's compatibility layer that lets many Windows games run on Linux.
v-sync ↩
Vertical synchronization, a graphics setting that waits for the monitor refresh cycle before showing a new frame to reduce tearing.
Wayland ↩
A modern Linux display server protocol used to show windows and handle input, intended as a replacement for X11.
X11 ↩
The X Window System, the older display server architecture widely used on Unix and Linux desktops.

Reference links

Related HN item