Measuring XWayland input latency

<scratchpad> [Rolling Structure: Opening B (The Empirical Suspicion / Personal Anomaly), Body B (The Escalating Systems Diagnosis), Closing B (The Infinite Appendix)] </scratchpad>

I've been reading Hacker News threads for years where users complain that Wayland "feels sluggish" compared to X11, which inevitably triggers a cascade of responses from desktop environment developers universally replying that the users are imagining the latency because Wayland has a much cleaner architecture that removes the legacy X server middleman. As a rule, human perception of input latency is famously unreliable because our brains naturally smooth over jitter. My default instinct when I see these sorts of subjective feeling arguments is to ignore them entirely unless someone can produce hard data. It doesn't help that users will overwhelmingly choose a laggy interface if it has slightly better window animations. But dismissing user reports based purely on the theoretical elegance of an architectural diagram without bothering to actually measure the physical hardware stack is a classic ops smell.

Fortunately, we don't have to rely on cocktail-party Econ 101 assumptions about whether cleaner code intrinsically produces faster execution. Marco Nett recently hooked up a hardware logic analyzer consisting of an Adafruit QT Py RP2040 and a BPW34 photodiode directly to a monitor to literally just measure the physical reality of the situation by timing the gap between a mouse click and the exact moment photons are emitted from the screen. This bypasses the OS entirely. Software polling for latency is notoriously fraught because you are asking the system that is lagging to accurately report its own lag, whereas using a photodiode means you are measuring the end-to-end reality experienced by the human retina.

When Nett bypassed the operating system abstractions and looked at the raw electrical signals, the data showed that rendering through Native Wayland takes 4.93ms of latency, whereas running that exact same application through XWayland takes 8.06ms. The difference is a mandatory, hardcoded latency penalty of 3.13ms just to bridge the legacy interface gap.

To understand how catastrophic a flat 3.13ms penalty is in modern hardware contexts, we have to look at the strict mathematical constraints of high refresh rate displays. If you are running a standard 144Hz gaming monitor, your entire frame budget before the display must physically draw the next image is exactly 1000 / 144 = 6.94ms. The mathematical reality is that adding a 3.13ms routing penalty on top of the graphics pipeline consumes 3.13 / 6.94 = 45% of the absolute theoretical render budget before a single pixel actually changes state on the screen.

|-- XWayland overhead (3.13ms) --||-- Remaining frame budget (3.81ms) --|
|<---------------------------- 6.94ms total --------------------------->|

If you drop a 360Hz e-sports display into the mix, the frame budget shrinks to 1000 / 360 = 2.77ms. In this scenario, the 3.13ms XWayland overhead is literally larger than the entire frame window. That means the compositor will deterministically miss every single vblank interval for a synchronous frame delivery.

That is a structural failure.

The physical reality of this latency injection is a fundamental consequence of how the abstraction was explicitly designed to cleanly separate concerns. It cannot be patched out in a weekend sprint. As documented by zamundaaa's breakdown, the XWayland bridge forces extra buffer copies. The pipeline dictates waiting for the X11 app to finish rendering, copying that buffer over to the Wayland compositor, and then waiting for the next frame cycle to actually display it. Depending on your IRQ affinity and CPU scheduler, this often means dropping the frame entirely if the copy misses the vblank window.

Let's look at the actual operations. In a native display environment without compositing overhead, a full screen application can do a direct page flip. The application renders into a buffer, tells the GPU to point the display controller at this memory address, and the hardware does it instantly on the next scanline. In the XWayland model, the application renders to a buffer, but because it doesn't own the screen, it has to tell the X server it's done. The X server then has to notify the Wayland compositor via IPC. The Wayland compositor wakes up, takes the X11 buffer, composites it with whatever else might be on the screen (even if there is literally nothing else to draw), and then issues its own page flip. Every one of those wake-ups requires a context switch. If the system is under any kind of load, the kernel's completely fair scheduler (CFS) might decide to park the compositor thread for a few milliseconds, instantly turning a 3.13ms penalty into a 16ms dropped frame.

This micro-level anomaly perfectly illustrates a macro-level industry pathology where UI compositing wrappers and clean architectural rewrites almost always trade objective physical speed for developer convenience. We can clearly see this normalization of deviance when we compare historical latency regressions across the industry.

As Dan Luu noted in 2017 regarding historical latency regressions, vintage 8-bit computers from the 1970s and 1980s routinely destroy modern multi-gigahertz machines in raw physical responsiveness precisely because they didn't have heavy compositing window managers sitting between the keyboard interrupt and the display register. The Apple IIe manages a full pipeline latency of roughly 30ms with a CPU running at a comical 1.023 MHz. To match that responsiveness today, we throw processors running at 4.0 GHz with tens of megabytes of L3 cache at the problem, and we still regularly fail because our software stacks require five different IPC hops just to draw a rectangle.

And if we look at Pavel Fatin's typing latency data, it proves that architectural rewrites designed to make cross-platform development easier routinely result in catastrophic performance cliffs. A native terminal manages a 5ms response time, while an Electron-based wrapper chokes on a 70ms delay. The developers of these wrappers will often argue that 70ms is "unnoticeable" to the human eye, which is trivially false if you have ever tried to play a rhythm game or type at over 100 words per minute.

Looking at the incentive structures driving open-source desktop development, the root cause of the XWayland latency issue is a completely predictable result of misaligned human incentives. The graphics rendering pipeline is operating exactly as designed. The cocktail-party consensus among Linux desktop developers is that modern composited environments are strictly superior because they prevent screen tearing and enforce security isolation. This is an entirely rational view if your primary metric of success is codebase maintainability and avoiding decades of X11 legacy spaghetti.

But if we are a project team locally optimizing for our own maintenance benefit, the math works out such that it is infinitely cheaper to tell users their subjective perception is wrong than it is to actually engineer a zero-copy synchronization pipeline that respects the physical constraints of a 6.94ms frame budget. Solving that problem requires doing brutal, unglamorous kernel-level synchronization work and untangling the GPU driver stack. No one gets promoted or praised on social media for shaving 3ms off a legacy bridge. Because modern software engineering cultures treat a 3ms penalty as an acceptable rounding error, developers implicitly pass a globally degraded experience onto the user, entirely convinced that they've improved the system because they are looking at neat abstract block diagrams instead of hooking up physical logic analyzers to the output pins. The users complain, the maintainers point to the clean architecture, and the actual physical photons continue to arrive late.

Appendix: Why "Wayland is just a protocol" is a functionally useless defense

Whenever anyone measures Wayland implementations and finds them wanting, someone will invariably point out that Wayland is just a protocol and the latency is actually the fault of the compositor (Mutter, KWin, wlroots, etc.).
This is pedantically true and structurally irrelevant. Users do not run protocols; they run implementations.
If every major reference implementation of a protocol incurs an identical structural penalty because the protocol's security and isolation models practically require heavy compositing and multiple buffer copies to function, the protocol is the root cause of the latency.
Trying to shift the blame to the compositors is the equivalent of designing a network standard that requires doing a blocking cryptographic handshake on every single packet and then blaming the application developers when the throughput drops by two orders of magnitude.
There is a persistent belief that if we just wait for faster GPUs, this overhead won't matter. But as we've seen with display refresh rates scaling to 360Hz and beyond, the physical time budget per frame is actually shrinking faster than IPC latency improvements can compensate for the required context switches.