Improving User-Accessible Vsync Controls

Brainstorm
, ,
1

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.

1 Like
2

Wayland is ‘fluid’.

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.

3

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.

1 Like
5

Never mind. It works great in a Kwin-only session, but it breaks the Plasma session for me :frowning:

1 Like
6

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.

1 Like
7

I too would like to see this implemented, and I also don’t use window effects/animations at all, so the “tearing makes animations look bad” thing is irrelevant to me.

Yes, this is going against the “every frame is perfect” thing that Wayland was/still is going for, yes it’s another niche feature that barely anybody is ever going to use, and yes, it is indeed true that way too many apps contribute way more latency than a 60Hz refresh cycle ever could (Electron stuff mostly), but still. I’ve been looking for this (anywhere in Wayland-land, not just KDE), and no compositor anywhere seems to have this implemented (Kwin only supports tearing for fullscreen apps, Sway has a force tearing option but also only works on fullscreen, and not much else seems to bother even with that)…

I really don’t want to be on Xorg anymore over this (though I am currently making myself run it with compositing for other reasons, but disabling it is so much better), it’s basically unmaintained and can barely handle e.g. video playback (without dropping frames) properly (yes I know that you won’t get videos to play properly with tearing, but that’s where I go out of my way to turn it back off… this is why this should be a user-accessible option), and future (and current in many cases) hardware compatibility is meh conceptually so I’d love to upgrade here, but…

I want my tearing back. And I’m not even that old, I was perfectly capable of running wayland for quite a while actually but went to Xorg “temporarily”, then had compositing disabled for a while and it’s a lot better imo.

Also, some apps behave terribly when running under a vsynced desktop: Electron stuff, for instance, is not good on composited Xorg but actually somewhat bearable if you turn it off (a lot better on Wayland, but still worse than with tearing on Xorg)… yes, that’s an application issue and not a server issue, but at least that’s another reason one might want to turn desktop-wide vsync off.

Also:

I have done this successfully now (compiling a hack of kwin that tears always).

anybody know what this patch is and what it does? Couldn’t figure this out myself… unfortunately I can’t contribute anything code-wise here myself.