I would like to see improvements to the tearing controls and sync options in general, and have them be made more transparent and configurable by the user. I recognize this is a niche use case, and kind of antithetical to the goals of Wayland, but it’s a showstopper for me.
I currently use X11 with the compositor turned off, not because of any technical limitations of my hardware, but because it is currently the most fluid and responsive desktop experience available, especially on 60hz monitors. I recognize the superiority of Wayland but can’t bring myself to switch until there is a way to make it “feel” better. I don’t mind tearing in most situations I use my computer for and would rather programs like text editors display interactive content quickly than wait for vsync.
That being said, besides having an option for the boomers like me who insist on having annoying screen tearing that developers worked tirelessly to eliminate, wouldn’t it be a good, user-centric change in the spirit of KDE to improve configuring synchronization options in general? I did some digging and noticed there was a move to dynamic triple buffering at some point, and that it can be configured using an environment variable only. Isn’t it worth having stuff like that be exposed in display or compositing settings? As well as possibly alternatives to increasing the latency in response to missed vblank, such allowing a tear in lieu of dropping the frame.
Cheers on Wayland being this mature. I hope I can switch eventually.
The concept of ‘fluidity’ is brought about by using animations for smooth transitions… and the actual time taken for those transitions becomes almost pointless once it goes down below maybe 100mS.
You have a strange concept of ‘vsync’ however, and this was one of the biggest issues with X11 which is a complete non-issue with Wayland. Vsync is handled by the compositor.
VSync would only cause a noticeable lag if your system is not able to maintain a consistent framerate. I needed VSync back with my 2000’s Nvidia to prevent tearing, it didn’t introduce any noticeable lag, but tearing is basically the visual problem caused by lag occuring during the display painting process.
In short, I never experienced any delay caused by vsync - because anything appearing between frames on your monitor are not visible anyway.
Fluid vs Responsive vs Snappy
What you’re conflating with ‘fluidity’ is actually ‘snappiness’. That means that, as soon as an app is ready to appear, it will appear instantaneously… no animation.
Screen Tearing
Screen tearing is also the enemy of fluidity - if a Window is to move up from the Taskbar to the top of your screen with a ‘magic lamp’ or ‘zoom’ (giving a ‘fluid’ transition) it is vital that there is no tearing.
Boomer
As a fellow boomer, I have to say that the greatest step forward in the Linux Desktop came (for me) with the final year of Compiz when I bought a simple i3-4130 processor with enough graphics power to handle the desktop - then the animations immediately became smoother, and the experience more fluid.
Dinosaur
I don’t think that KDE developers should waste too much time trying to refine the X11 experience.
You have a strange concept of ‘vsync’ however, and this was one of the biggest issues with X11 which is a complete non-issue with Wayland. Vsync is handled by the compositor.
Yes, and this is handled far better on Wayland than it is on X11 compositors. This does not change that it inherently introduces latency, across all major desktop operating systems (which all force it since Windows 8), including the good implementations, and one of the killer features of Linux with KDE for me has been able to just use it without a compositor to avoid it. Granted, this is not a latency most people would notice or care about. For me, it is a latency that I could instantly pick out in a blind test and would prefer the option to avoid.
I am asking for a feature in the compositor to disable the compositor-enforced vsync desktop-wide.
VSync would only cause a noticeable lag if your system is not able to maintain a consistent framerate.
You are conflating latency and framerate drops. I am running a system with a 5600X and 6700XT. It is safe to say I am dropping zero frames here.
but tearing is basically the visual problem caused by lag occurring during the display painting process.
Tearing is the natural result of not waiting for a screen refresh to output visuals.
What you’re conflating with ‘fluidity’ is actually ‘snappiness’. That means that, as soon as an app is ready to appear, it will appear instantaneously… no animation.
I have animations globally disabled on my composited sessions anyway. It does not make a difference. There IS delay. There is no reason to introduce a tearing protocol to reduce delay in fullscreen gaming if delay is not an issue in the first place.
It is probably not considered by most developers that one would even want to go further than that use case since, frankly, people who care about vsync latency outside of gaming that much are kind of weirdos. I know I am one.
I don’t think that KDE developers should waste too much time trying to refine the X11 experience.
I agree. I would like to leave this sinking ship myself. I am simply waiting on a single feature.
I have done this successfully now (compiling a hack of kwin that tears always). Using my distro’s build system and installing at as a package instead of hacking together the install seems to work for me. But there seems to be some synchronization logic or something that is bypassed specifically during direct scanout that causes stutters when running tearing across the full KDE session. Standalone kwin from a tty appears to not be affected and is smooth.
