Hacker News Reader

Comment by retatop | Hacker News Reader

Isn't Wayland always one frame delayed compared to Xorg to avoid tearing or has that been changed? If so, his very high refresh rate would minimize that effect

View on HN

I don't think there was ever a design to be one frame behind.

Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").

Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.

And for the complete picture, X is predominantly used with a compositor, so that same extra latency exists there as well.

It's generally a single checkbox to turn off compositing in X11, for precisely this reason.

You can also disable compositing conditionally in KDE, such as when a game window is opened.

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.

Yes, but the same is true in Wayland and it's automatic as well. Full screen applications don't require compositing so they typically don't, and this was the case in MOST X11 compositors as well.

Turning off compositing before launching a game is maybe a bit misguided, sort of like turning on the "classic theme" in Windows 7 before launching a game. It might save some memory, sure, but latency should be identical.

> latency should be identical

Should be, but very clearly isn't.

The results show it's identical. Only XWayland suffered any significant degradation, and even then we're talking <5ms which is imperceptible.

Those results depend on having a 500hz monitor. There's a world of difference between a mildly-buggy rendering loop's 1-frame delay or missing a vsync deadline causing a 2ms delay vs a 16ms delay.

Tearing can theoretically improve latency for the part of the screen that's below the tear, but in any case where you could actually benefit from it the difference would be at least order of magnitude smaller than the duration of one frame.

Reply on news.ycombinator.com