Not sure if feature requests are allowed here, and I'm getting mixed messages on whether they are, so I'm adding this as wishlist severity since this counts as a Wayland showstopper/feature parity issue for me. Feel free to take it down. On X11, it is possible to bypass compositor-enforced Vsync by disabling the compositor entirely. This is currently how I use my systems, because it is noticeably more responsive than letting it wait for Vsync on either composited session. This causes the screen to "tear", which I do not mind. There is currently no alternative to doing this on the Wayland session, outside of the fullscreen gaming usecase. It is important that the user can opt into tearing across the desktop, so that applications besides fullscreen games (such as windowed games, drawing software, and general usage) can retain responsive behavior in the absence of a specialized high-refresh rate monitor.
>This is currently how I use my systems, because it is noticeably more responsive than letting it wait for Vsync on either composited session Blindly copying what might have improved performance on X11 into a wayland session isn't the right approach. Kwin not vsyncing whilst clients are waiting on frame callbacks anyway would achieve absolutely nothing especially for non-gaming apps, it's important to take the whole stack into account. We will continue to improve performance, but that means different fixes.
> Blindly copying what might have improved performance on X11 into a wayland > session isn't the right approach. I'm referring to input latency and not general performance. Not waiting for Vsync probably takes more system resources in general even though it is more responsive. Waiting for Vsync causing latency is pretty universal across operating systems, it is simply disregarded as tearing is less desirable than ~16ms delay for most users. >Kwin not Vsyncing while clients are waiting for frame callbacks would achieve absolutely nothing anyway. I am not sure how it is implemented, but another Wayland compositor has a forced tearing PR in the works that definitely does improve input responsiveness on 60hz displays and works in windowed applications. The "allow tearing" option in fullscreen games on Kwin achieves a similar improvement in input delay that feels in line with X11. I don't know if this means the compositor is spamming the client with frame callbacks or what, but it feels identical to uncomposited Xorg and very smooth whereas non-tearing situations feel like I am using my computer underwater. >Especially for non-gaming apps. The difference is the same for gaming and non-gaming apps. Gamers speak up about it because for their use case it is unacceptable.