Ubuntu 20.04 GNOME X.Org vs. Wayland Session Performance Impact For Gaming

[jacob]

No, you're just limiting your own comprehension. Of course can one support it and replace it. The support is what is necessary for it to replace it. So you keep splitting hairs for which nobody cares. You could equally argue that it is slow, because that what it is supposed to be. And while you may be right does only nobody care for it. And until you get this, what it is and what people want it for, will nobody care for an interpretation as to why it fails to deliver. So you can talk about it forever in circles, just nobody will listen anymore or care for it when all it does for the is to throttle the performance, even when it's just games.

You're talking out of you arse. Wayland was never meant to "support" X11 because it was never meant to be a next-version X11 or even a successor to X11. It was meant to be a radical, clean sheet design, totally (and perhaps deliberately) incompatible with X11. And so it is.

And if you have some actual hard facts supporting the claim that Wayland is somehow inherently slow (never mind the question how an API specification by itself can be slow) then please share them; saying "it's sloooow because I say so" doesn't impress anyone.

[sdack]

You are contradicting yourself. You can't support something and replace it at the same time. ...

No, you're just limiting your own comprehension. Of course can one support it and replace it. The support is what is necessary for it to replace it. So you keep splitting hairs for which nobody cares. You could equally argue that it is slow, because that what it is supposed to be. And while you may be right does only nobody care for it. And until you get this, what it is and what people want it for, will nobody care for an interpretation as to why it fails to deliver. So you can talk about it forever in circles, just nobody will listen anymore or care for it when all it does for the is to throttle the performance, even when it's just games.

[jacob]

It was supposed to support X11 and to replace it, which is why it has the support for it or we wouldn't be having this discussion.

I guess you'll never stop making excuses and keep trying to side-track the lack of performance. It's only not going away. Only people will go away and stop paying attention to it, which I assume is why after all these years it just doesn't find many fans.

You are contradicting yourself. You can't support something and replace it at the same time.
Wayland was supposed to replace X11, not support it. There is a compatibility layer for X11 apps on top of it (not as part of it) as a stopgap measure.

As for "the lack of performance", there isn't any. At the risk of repeating the old cliche, Wayland is a protocol (or more precisely, it's in fact an API), and protocols don't have performance. Drivers and compositors do. With a proper driver and well implemented compositor, as of today a Wayland desktop outperforms anything based on X11.

Regarding Wayland's "fans", it's a technology, not a fanclub. Failed techs usually have "fans", prospering techs have developers, users and, of course, critics. Wayland has behind it virtually all the Linux graphic stack's developers. Fedora uses it by default (which means anyone running Fedora has been relying on Wayland for quite some time, sometimes maybe without even being aware of it); on Ubuntu it's exactly one click away and will presumably become default once the LTS release is out of the way; toolkit developers target Wayland first and X11 second; all new features are developed for Wayland first and X11 (sometimes) second.

I don't own any Wayland-related stock and am not a Wayland developer; you could say the only thing I really care about in this case is that X11 really had to die a long time ago. But I see things as they are. Wayland is the future of Linux graphics. Some problems currently exist (but honestly, not nearly as many as with X11) that are being addressed; in fact the current generation of software such as the GNOME 3.36 discussed in this thread has made huge leaps in that regard. Whiners of course are going to whine, especially those who believe that evolution should have dropped dead in the 1980.

[sdack]

Wayland wasn't supposed to support X11 ... yet you can optionally run a X11 server on top of them and it's the same for Wayland.

It was supposed to support X11 and to replace it, which is why it has the support for it or we wouldn't be having this discussion.

I guess you'll never stop making excuses and keep trying to side-track the lack of performance. It's only not going away. Only people will go away and stop paying attention to it, which I assume is why after all these years it just doesn't find many fans.

[oiaohm]

It most certainly did not take 15 years of X11 development to implement clipboard. It was there from 1989, only a year after X11 first release in 15 September 1987.
https://en.wikipedia.org/wiki/Inter-...entions_Manual

Read that again.

X deliberately specifies "mechanism, not policy" for how windows interact. As such, an additional specification beyond the X protocol itself was needed for client interoperation.

This line particularly and that line is slightly wrong as I will point out at the end. Inter-Client Communication Conventions Manual (ICCCM) like it or not is not part of the X11 protocol and still is not part of the X11 protocol. This leads to many parties implementing X11 stuff and deciding to ingnore ICCCM. Yes 1.0 and 2.0 of that standard are not 100 percent compatible with each other so you have to implement both. Add on the 10 others done you have a mess. There were 2 verations done in gtk, 3 in Qt, Tk made another... Basically toolkits cause a plague of incompatibility because that standard was optional.

Wayland wl_data_source and wl_data_offer was in wayland from the start as in the clipboard. So it did not take 15 years for the wayland protocol to have clipboard as it is in fact a day one Wayland protocol feature. The dispute is in implementation of compositors is how to do clipboard securely and not be a data leak that been the slow bit.

Common Desktop Environmnet (CDE) had system tray since 1993 and there were many other proprietary desktops which had it even earlier (IBM AIX, Silicon Graphics Irix, Apollo).

Lot of the parties you listed their implemented their own quirked versions of X11 protocol and servers.

https://blog.martin-graesslin.com/blog/tag/systray/

System Tray is still a wild wild west. Yes that is the 1993 CDE system tray applications don't work on new KDE. If you dig around they don't work on Gnome either.

Welcome to another area of multi incompatible standards and implementations that have multi cases of I don't work any more or I don't work on this desktop but I work on this other one.

Many of the modern desktop features did not exist when X11 was developed, so you can't blame X11 for not having them, or for taking a long time to implement them.

And that in fact wrong the issue is not that the stuff was not implemented the problem is it was not made part of standard/protocol and standardised. When x.org took over the X11 protocol and the maintainer to release new versions the first thing they did was make ICCCM mandatory feature yes this is 2004 when x.org came the official reference for X11 protocol did ICCCM come part of it. A lot of features were added to the X11 protocol over the years 1993 X11 protocol is still being modified. Reality when all the desktop features appeared X11 protocol was open to modification or making standard with new desktop feature mandatory by standard yet this did not happen for a hell long time.

So the year when clipboard support comes part of X11 protocol required protocols is 2004 in other words 17 years since the start of X11 or 16 years from when ICCCM was first proposed. Basically that gives the 16 years for 2 versions of ICCCM and 10 other things doing the same thing to pop up that are all incompatible with each other in different ways.

Welcome to one of the major reasons why X11 protocol came a disaster mess of protocols there was no requirement to propose problem sit down and work out one way todo it. Instead each party implemented their own and worked on the idea of survival of the fitest.

Yes the survival of the fittest idea is also what lead to the KDE vs Gnome disaster where neither side had to consider compatibility with each other early on 2004 is when this survival of fittest idea slows down and focus on proper lets make unified standards between desktop bits start.

X11 protocol was developed early on in a very out of control way. Wayland has started with very strict policy on how stuff has to be done from the start line.

I also love that over 70 percent of the optional protocols x.org supported in 2004 were internationally broken and when no one complained removed since 2004 to now. And they are still breaking and removing optional protocols and some of these protocols turns out person wrote them and no application ever used them. This explains why Wayland Protocol has a lean and mean policy.

X11 protocol and it optional protocols have been a total disaster mess.

[jacob]

Just more of the same excuses. If Wayland wasn't supposed to support X11 then it's actually quite surprising to see that X11 software runs under it. So it's a pretty bad excuse you're trying to make. Nobody but a few nerds care how it's handled under the hood, but what matters is the end result. And that's what is being criticised here. Nobody cares if it can nit sweaters, too. That's not what is being benchmarked here.

Wayland wasn't supposed to support X11 any more than Windows or MacOS weren't supposed to support X11; yet you can optionally run a X11 server on top of them and it's the same for Wayland.

[jacob]

You have my attention. Could you share how you enabled RR scheduling?
The only useful mention I could find with a quick DDG search is in this page on Arch Linux' bug tracker. Is this correct?

gsettings set org.gnome.mutter experimental-features "['rt-scheduler']"

That's step 1 (for some reason this command didn't work for me, I had to do it using dconf editor).
But then you need to allow Gnome Shell to actually use RR scheduling; I guess the proper way would be for it to use rtkit but that's not implemented yet, so in the meantime you need to do:

sudo setcap CAP_SYS_NICE=+ep /usr/bin/gnome-shell

Log out, log in again, and voila!

PS: you need to redo the setcap command every time the gnome-shell package updates.

[sdack]

Wayland doesn't implement X11 at all, that's kinda the point of it.

Just more of the same excuses. If Wayland wasn't supposed to support X11 then it's actually quite surprising to see that X11 software runs under it. So it's a pretty bad excuse you're trying to make. Nobody but a few nerds care how it's handled under the hood, but what matters is the end result. And that's what is being criticised here. Nobody cares if it can nit sweaters, too. That's not what is being benchmarked here.

[Britoid]

in case you really wondered it's because xwayland clients are not clients of wayland, they are clients of x11. and their decorations are drawn by x11 window manager as usual in x11. see, it's really that simple

This 100%.

If you enable looking glass on GNOME, you'll see the XWayland Windows and Wayland windows as far as Mutter is concerned are just textures.

[pal666]

Then how come they did it for XWayland clients? That makes no sense!

in case you really wondered it's because xwayland clients are not clients of wayland, they are clients of x11. and their decorations are drawn by x11 window manager as usual in x11. see, it's really that simple