In upcoming versions of GNOME, one quite big change had now been merged in for those of you using it with Wayland.
Yesterday, the "Wayland surface fullscreen unredirect" code was merged into Mutter (GNOME's Wayland display server and X11 window manager). What this actually means: for people playing fullscreen games on GNOME + Wayland, it can now bypass compositing, which you don't usually want when the whole screen is filled with a game which can help with performance.
One problem we have on X11, is the issue of screen-tearing when this is used. However, it appears that won't be an issue on Wayland. As Red Hat engineer, Jonas Ådahl, mentioned in the comments:
No, there should be no more screen tearing compared to no fullscreen unredirect. Wayland has the concept of "holding" buffers, meaning clients are not allowed to write to them until they are "released". Without being unredirected, we "hold" a buffer until it's replaced with a new attached buffer; the difference with scanout is we "hold" it a bit longer - until it will no longer be scanned out by the driver. A client can still violate the rule and write whenever it wants, but as long as the client is well behaved, you'll get no tearing.
This is one more feature checked off the list for Wayland, to bring it up to a great standard for the future of the Linux desktop and Linux gaming. Now this is merged in, it should be shipping with GNOME/Mutter 3.38 in September and then it's up to each Linux distribution to pull it in.
Quoting: vipor29i have noticed screen tearing is becoming less and less of a issue which is nice.though i have a 165hz 1440p display so once i enable that im good to go.
I can't remember ever seeing screen tearing when using GNOME on Wayland. Stuttering has been a problem though, but it's pretty much gone as of version 3.36. Actually it was mostly fixed in previous releases but there was one game (DSII:SotFS through Proton) which didn't work properly until 3.36. It wouldn't go into fullscreen so it was always in a window, and moving the camera around was extremely jittery because frames weren't presented at the right time. Working fine now though :)
A cop who is directing traffic may have to redirect traffic around, say, an accident, but, once everything is cleared up, the cop resumes directing traffic --- not un-redirecting traffic.
All the same, and however much it's doublespeak, it sounds like it's generally a good thing for gaming using Wayland on Gnome, so that's nice. :)
Last edited by Nanobang on 18 April 2020 at 12:32 pm UTC
Unredirecting on X.Org on AMD Mesa, never causes screen tearing, unless v-sync is also turned off in game. Sometimes you want that. So adding unredirect into Wayland is an atypically user-friendly move from Gnome! I’m pleasantly surprised.
Quoting: HoriI'm no graphics expert but I'll take a stab at a justification for this bit of technical jargon. Expect some simplification (or "lies to children" as Pratchett et al. put it in one of the Science of Discworld books).Quoting: NanobangI imagine there's some coding reason that whoever came up with it was unable to use the simpler and saner existing word "direct." After all, to un-redirect, as far as I can see, simply means to direct.But in this particular case, although I don't really know the technicalities, I think your argument could make sense but I still prefer "unredirect".
When people talk of direct rendering, they mean drawing stuff directly on your screen. Now, if you want to do even rudimentary desktop composition, you need to redirect the rendering of your various applications to off-screen buffers, which then get composited onto the screen. And if one of these applications should be able to write directly on the screen and avoid the desktop composition pipeline completely, for performance or other technical reasons, you have to avoid redirecting the rendering of that particular application. Here the redirection is intentionally and actively disabled, or in short, the rendering is "unredirected".
This might absolutely infuriate people who actually know about this stuff, but I'll accept that risk. Corrections welcome. :)
See more from me