XWayland 23.2 RC1 Brings Tearing Control, Resizable Rootful, Emulated Input

[stiiixy]

To everyone offering advice on his situation...

[MrCooper]

Resizable rootful? Does this mean that we're not limited to fullHD anymore? That's huge!

Not sure what you mean, there was no Full HD limit.

It means that if you run

Xwayland -decorate

the resulting decorated window can now be resized (and it reports the new size to its clients), whereas before it was fixed at the original size.

[Weasel]

Tearfree was an impossible luxury feature when X11 was launched. Wayland had already implemented Tearfree on the drawing board.

And forcefully disallowed tearing, which made it even worse, literally ruined competitive gaming. Not everyone is a mobile peasant.

[oiaohm]

And forcefully disallowed tearing, which made it even worse, literally ruined competitive gaming. Not everyone is a mobile peasant.

There is a problem here X11 has been wrong.

https://www.hp.com/us-en/shop/tech-takes/what-is-screen-tearing

Screen tearing is an effect seen in moving pictures where the display suffers from distortion due to incorrect rendering of fast-changing images on the screen. Depending on the nature of the visual artifact, this may appear as a short-lived distracting glitch or a persistent distortion that can cause eye strain. In all cases, the overall effect is to disturb the visual experience and distract the viewer.

It make sense for screen tearing to be avoided by default. For almost everyone not doing competitive gaming avoiding screen tearing is a good idea.

X11 tear handling logic is backwards to what it need to be. Wayland where applications declare they want tearing is the more correct way todo it.

Screen tearing is not a straight forwards problem. Yes Screen tearing lowers latency but increases eye strain and epilepsy issues and can effect user experience adversely.

Weasel not everyone is a gamer. Wayland work to make tearfree have lower latency cost has been a really good thing the more thing that can be done tearfree the better. X11 design has a lot of overhead when you enable tearfree.

So Weasel like it or not forcefully disallowed tearing did not make it even worse the change made somethings better. Depends on the competitive computer game some competitive e-sport games reducing eye strain is advantage of forced tear free. The problem is most answers are not a binary answers.

[gotar]

Tearfree was an impossible luxury feature when X11 was launched. Wayland had already implemented Tearfree on the drawing board.

On their drawing board was no-tear-at-all, that's why tearing possibility was so complicated to push through.

[gotar]

The problem is most answers are not a binary answers.

The problem here was that they were actively against implementing tearing at all, so they were binary.

There is a huge difference between "if you want something then post a patch" and "we won't accept such feature because it's against our ideology".

[Weasel]

There is a problem here X11 has been wrong.

https://www.hp.com/us-en/shop/tech-takes/what-is-screen-tearing

It make sense for screen tearing to be avoided by default. For almost everyone not doing competitive gaming avoiding screen tearing is a good idea.

X11 tear handling logic is backwards to what it need to be. Wayland where applications declare they want tearing is the more correct way todo it.

Screen tearing is not a straight forwards problem. Yes Screen tearing lowers latency but increases eye strain and epilepsy issues and can effect user experience adversely.

Weasel not everyone is a gamer. Wayland work to make tearfree have lower latency cost has been a really good thing the more thing that can be done tearfree the better. X11 design has a lot of overhead when you enable tearfree.

So Weasel like it or not forcefully disallowed tearing did not make it even worse the change made somethings better. Depends on the competitive computer game some competitive e-sport games reducing eye strain is advantage of forced tear free. The problem is most answers are not a binary answers.

No you're completely wrong, the option that is least restrictive should always be the default. You can force V-Sync on the driver.

But you can't "undo" V-Sync once it's forced except not forcing it in the first place (requires cooperation of every part in the entire stack that forces it).

If Wayland forces it for example you can't "undo" it in the driver, because that's the equivalent of walking backwards in time.

[oiaohm]

The problem here was that they were actively against implementing tearing at all, so they were binary.

There is a huge difference between "if you want something then post a patch" and "we won't accept such feature because it's against our ideology".

There is more to this and it relates to the answer I am about to give Weasel..

No you're completely wrong, the option that is least restrictive should always be the default. You can force V-Sync on the driver.

But you can't "undo" V-Sync once it's forced except not forcing it in the first place (requires cooperation of every part in the entire stack that forces it).

If Wayland forces it for example you can't "undo" it in the driver, because that's the equivalent of walking backwards in time.

There is a problem here. Force V-Sync on in the driver is this right because vsync is always forced on in the driver like or not weasel(there is a driver internal thing you missed).

https://wayland.app/protocols/tearing-control-v1

Do notice the wayland tearing protocol that you can turn sync on or off on the buffer. Do note this is a hint that compositor can ignore this is important.

Lets say user has epilepsy so cannot have the flicker tearing generates user need to be able to force tear free.

Lets say you force it on at driver and the buffer does not have sync information that is required for vsync what is the effect of this. X11 implementation tells us exactly what this effect is the effect is +1 frame of latency. Tear free X11 force on by driver at least 1 frame slower than Wayland tear free because you have to wait for the next buffer to be created before buffer can be classed as complete because without the sync data this is the only way you can know a frame is complete to be rendered tear free..

Now what is the overhead of allowing tearing on Wayland less than 0.1 of a frame(so low its hard to measure).

Least restrictive default is in fact implement everything vsync compatible and for async/tearing just ignore the vsync information on buffers that marks when a buffer is completed.

Its one of those things Weasel you did not think enough your claim that undo V-sync without cooperation of every part in the stack is also wrong. What happens to vsync if all the buffers including incomplete ones are simply flagged as completed that right vsync on but functionally disabled.

This was kind of the problem with early wayland where should force vsync information flag to be to say this buffer is always complete even if it not.

Wayland developers yes went for vsync always on in the wayland core protocol. In theory the flag saying this buffer will report as completed always could have been implemented in opengl/vulkan without being in Wayland protocol and generated the same effect as Wayland tearing control.

Weasel the fun thing you never considered is that you can 100 percent emulate async tearing with vsync on but you cannot 100 percent emulate vsync with async and that is the way it is. Vsync you need more information recorded with buffers than async and emulating async with vsync is basically go let ignore the vsync extra sync information and read as saying the buffer is complete be it complete or not.

Weasel the cannot undo Vsync you never asked the question do you need to undo vsync to render async? The answer is no you don't need to undo vsync to render async. There was a bit of creativity.

Yes high level graphic driver developers are not the best at expressing themselves. Wayland always having tear free/vsync on does make absolute sense when you are a graphics driver developer who knows that async on your GPU is always lie because complete frames have to be sent to monitor and the sent buffer at some point is a snapshot because the output to the monitor is always vsynced. This has been the problem people saying "We want vsync off" to graphics driver developers where vsync is never off. What the person wanted was vsync sync information to be ignored to emulate async instead.

Weasel when at the graphics driver level vsync is always on why should this not show though to user space? You said least restrictive option by not showing vsync though to user space the result is your restrict applications from using vsync correctly(X11 protocol does this so creating x11 +1 frame problem when vsync is enabled). Yes weasel you have the problem backwards. Lots of people have had vsync/async problem backwards and developers of Wayland were not very good at explaining how everyone had it backwards.

Vsync in digital graphics stack is the mandatory feature and async(tearing) is the optional feature made up by emulation on top of vsync.
This single line should explain to you why we must turn of vsync now fall in heap. A gpu without vsync cannot do graphical output these days. There is a reason why I said digital. Analog graphic stacks of old could ignore vsync but really the majority of people don't have analog monitors any more. Vsync off really does not exist any more for 95%+ of users and the users have not noticed due to how well async can be emulated on a vsynced output.

[Weasel]

Weasel when at the graphics driver level vsync is always on why should this not show though to user space? You said least restrictive option by not showing vsync though to user space the result is your restrict applications from using vsync correctly(X11 protocol does this so creating x11 +1 frame problem when vsync is enabled). Yes weasel you have the problem backwards. Lots of people have had vsync/async problem backwards and developers of Wayland were not very good at explaining how everyone had it backwards.

Wtf are you talking about? V-Sync is not a privileged operation. Any application can do it, if it wants to. It doesn't need special privileges.

The problem is that when an application enables V-Sync, anything further down the stack will be forced to use it. So the compositor forcing its use by default is retarded, because this forces every app to use it, since they all go through the compositor in Wayland. If you force V-Sync on the driver, then of course everything will be using V-Sync since the driver is at the top of the chain.

What's so hard to understand?

Think of it like FPS limits. An app can limit its own FPS without any special privilege, simply drawing less frames per second. If the compositor limits it (Wayland does AFAIK), then all the apps that use it will be forced to limit the FPS the same way. This effect does not propagate upwards: if an app forces its own FPS limit, the compositor is not affected.

It's a one-way operation. And for one-way operations the default should be the least restrictive as I said, in this case, no V-Sync at all (i.e. tearing by default). Apps can enable it if they want. Or the user can, on the compositor, if it's an option. An option, not a forced feature.

Christ.