wlroots Merges Wayland Tearing Control Support

[phoronix]

Phoronix: wlroots Merges Wayland Tearing Control Support

The wlroots Wayland compositor library used by Sway and other Wayland compositors to help with the heavy lifting has merged support for the tearing control protocol...

https://www.phoronix.com/news/wlroots-Tearing-Control-Merged

[rhysperry111]

I'm interested in how this is actually handled on the compositor side of things. How for example does it work if one window on a workspace has enabled tearing, but all the rest behave as normal?

[Kjell]

This is already supported by Hyprland!

[Hans Bull]

Too bad that KWinFT did not gain more traction.

[Quackdoc]

I personally dont see myself using this since the latency of wayland is already small enough, and I dont see the need to enable tearing

[pWe00Iri3e7Z9lHOX2Qx]

Too bad that KWinFT did not gain more traction.

Why? Support for this was already merged into kwin several months ago around the same time the merge request was created for wlroots.

[binarybanana]

Such a bad faith name. No one actually wants to "enable tearing". What people want is to lower input latency which can be achieved by disabling vsync. The tearing is just a side-effect.

[Quackdoc]

Such a bad faith name. No one actually wants to "enable tearing". What people want is to lower input latency which can be achieved by disabling vsync. The tearing is just a side-effect.

how is it bad faith? you are literally enabling tearing, on a mailbox/triple buffer setup, your latency is 1 frame of whatever the monitors cycle is. the only saved latency is during the tearing. hence enable tearing

[Weasel]

how is it bad faith? you are literally enabling tearing, on a mailbox/triple buffer setup, your latency is 1 frame of whatever the monitors cycle is. the only saved latency is during the tearing. hence enable tearing

I don't think you understand how triple buffering works. It's made to smooth your fps, not to decrease latency.

In fact, it will increase latency, unless you're very fps bound and can't keep up with the monitor refresh rate, since it will draw a frame ahead and then wait.

People have this delusion that it will keep on updating that frame until the old one on the backbuffer gets displayed/swapped. But that's not what happens, because if it did, you'd have "unrestricted" FPS/GPU usage (it needs to continually render). They don't do that, and let's be honest, people who praise triple buffering always do so with Vsync which caps your freaking fps.

So once it draws something, it freaking keeps it, and you're going to receive later, the old drawn frame, aka you have latency. It doesn't continually draw so that you get an updated frame when your monitor can display it, because it doesn't want to waste resources on discarding the old one.

Boomer priorities vs gamers you know.

[Quackdoc]

People have this delusion that it will keep on updating that frame until the old one on the backbuffer gets displayed/swapped. But that's not what happens, because if it did, you'd have "unrestricted" FPS/GPU usage (it needs to continually render)

the confusion comes from both being valid "triple buffer" implementations Triple buffer means literally what it says, having two buffer instead of one it's up to the implementation to do a hold or a discard (this is but one of many undefined opengl behaviors). opengl style is traditionally is this method (this is why fps does increase on windows often when you enable it, nvidia calls this fastsync btw) keep in mind wayland doesn't need to "run" at an fps, it can redraw when an app needs it to. this is similar to afaik, how most compositors work, the compositor will constantly update every single new update it needs to. it then sends the new frame.

this is why I explictly mentioned mailbox above and first. since mailbox is this behavior