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

[tildearrow]

tildearrow So you don’t like the technical cornerstones of Wayland. Then don’t use it.

In fact I am not using it.

So you disagree with the Meritocracy governing Wayland. Then don’t use it.

The corrupt "Meritocracy".

So you realized Qt is buggy under Wayland. Then fix* Qt or move to better options.

We need to fix Wayland. Qt devs are just showing how broken it is.
They don't feel like making a forced CSD border. This is how they boycott the lack of SSD support in GNOME.

They're like "OK, here is your CSD border. Happy?!"

This Holy War against Wayland is just silly as the Holy War against systemd. No one forced you to even look at Wayland.

Well, your crusade is causing the holy war. The excessive fanboyism and inability to see real problems.

*Remember to sign the CL-

*screams everywhere*
*tries to push him to the floor*

YOU ARE SO ANNOYING!! SO ANNOYING! THIS IS A prime example of your trolling! All day! CLA! CLA! CLA! GNOME is the best! Qt sucks and the rest of desktops do too!

This is the worst I have seen in my entire freaking life!

[tildearrow]

You have a problem here. You have not worked out that Microsoft Windows is in fact CSD. That right windows is client side decorations done by the toolkit of windows. This is why applications can simply splice in buttons into the window bar if they want it. Server side decorated you cannot in fact do that splice into window bar.

OK, look. I really wanted to quit but you type way too much that I seem to be forced to respond.
Windows. is. NOT. CSD. It looks like CSD, but it is not.
Windows does provide facilities for CSD applications, and some other APIs to hack the decorations and insert your own buttons.
However this does not mean that the entirety of Windows is CSD!

On the other hand, GNOME has NO facility for SSD applications because they just refuse to implement it for no actual reason. That's the difference there.

So this is not right because CSD is how Microsoft Windows works the thing is most applications are either using the single toolkit windows provides or there toolkit is copying the windows settings you do see odd applications like winamp that went stuff it under windows as well. X11 also has problem that application cannot always tell when windows manager will be doing server side decoration so you can end up with doubled or none at times.

Yeah but at least it's less likely than on the Wayland ecosystem.
GTK under Windows skins itself to look like Windows by default, and Qt does the same.
Lots of C# applications using Windows Forms also look like Windows. The majority of the OS looks like Windows.

Under Wayland, due to this CSD crap, some applications look like GNOME/KDE/whatever and some others do not.

That default skin in fact turns up under windows with Qt applications from time to time when someone builds Qt by mistake without the Windows platform appearance integration stuff.

But at least it's still using SSD! It is being decorated by the system, unlike in Wayland.

Plus, you know, this will be a nightmare for AppImage-relying developers because they can't even set a skin and therefore use the default one.
You are just finding excuses to never fix the problems.

That is not always true. Think XMMS it is client side decorations under X11 and its not the only one. So the reality with Xwayland or bare metal X11 server is you need both client side and server side decorations.

So shall be the case with Wayland too. CSD and SSD.
Yet another excuse to never fix Wayland.

Yes it annoying and the problem will not be solved by server side decorations alone we need more unity in themeing across the complete desktop like it or not client side decorations are here to stay on X11 desktop and wayland..

Yeah, but at least having SSD sort of mitigates the problem....
...plus come on did you think about games?! Nobody is going to spend the time making a decoration for a single protocol that few people use?!

(yes, there are people who play in windowed mode)

This is true but you have missed physically handy-caped need to script their desktop. This is not want this is if they cannot they cannot use the desktop at all.

Add them to the list as well.

Drop this but. The reality is AT-SPI2 is the interface for the physically handy-caped if there is anything a power user wants todo scripting their interface it needs to work though this for the physically handy-caped. Why should wayland have a interface for power users that results in the physically handy-caped being left high and dry without the features they need.

Look. The data query protocol must be generic, and cover most use-cases, accessibility included.

This is not in fact true. PipeWire screen capture with wayland is lighter than screen capture with X11 server. Because you can use the direct drm layer so use the gpu cards onboard encoder or other methods to avoid massive load.

I just hope so...
XSHM grabbing does add CPU overhead...

This is you ignoring problem of modern day hardware. In fact not that modern. Some of the early LCD screen did not have scaling either. So of cost cutting that appears in some Hidpi monitors/tv is limited scaling modes. So directly control screen is no longer such a hot idea. You need a man in the middle to go is the request with this screen sane. If your request is going to end up with a 1 inch image in the center of you screen that you cannot really use you don't want it to happen.

The reality is the GPU is just as capable if not more capable at scaling image than the scale chip that might be built into the monitor. Please note I worse scale chip that might be built into monitor not all monitors are capable of scaling anything.

Please stop making excuses.
I have this CRT monitor that I plan to use for some retro-gaming. Yes. I need to be able to set modes so that it looks near-native.

Other people with Raspberry Pi-based cabinets may be complaining too.

This may be a niche but how come Windows still supports it? Stop going the Apple way!

Ugh, it looks like Wayland was made by secret Apple fanatics...

This is your again being simple minded. This is what "Variable Refresh Rate Support" is about doing better. Lets say you are playing Turrican at 50Hz you puase and now want to play a youtube video that is at 30 frame per second to get some game hints. Setting one refresh rate really does not work well. GPU are also these days able to fake this fairly well when you have a monitor that does not support particular refresh rate well.

What about if I play windowed? *sighs*
Then VRR is not going to work!

Changing refresh rate to a per application thing instead of global thing is the way forwards like it or not.

Lot of these old ways of doing things going forwards are just straight wrong for the future.

*sighs*
You know, VRR miiiight come in handy to switch refresh rates faster... but... ugh

Everything you just stated here is because XWayland is in fact conforming to X11 protocol specification.

Well, but the presenting is being done the wrong way! Arcan did it right! XMir did it right!
Why is XWayland using a FREAKING polling method! This leads to severe untolerable stuttering!
I have tested it last time, and it was horrible. I can't lie.

[jacob]

That's nice.
Short of analysing source code and Git logs, I don't know how to move from here, given the... undocumented state of this feature, so I hope I'm not bothering you by asking this.
Do you happen to know which GNOME Shell version started supporting this, and if this is a feature that has to be enabled at compile time? I suppose if it's not enabled at compile time, then some distributions might not have it in their shipped binary.

Also, what is displayed at /org/gnome/mutter/experimental-features in the "Custom value" box in dconf Editor? Mine shows

['rt-scheduler']

which should be fine, given the type is "String array".

Edit: found the relevant commit that adds information to the dconf XML.

https://gitlab.gnome.org/GNOME/mutter/commit/dae2c1d420ed272710ac55b7a00f6787e5c0e762

It was committed 10 months ago, so it seems to be present in a stable version starting with GNOME 3.34.

AFAIK it was merged in at some point during the 3.34 development cycle so the stable 3.34 release should have it (but I don't know how well it works there; I'm using it on 3.36). I also think it's part of the default build options so standard distros should have it. In my case it works out of the box on Ubuntu; I presume Fedora should have it too given that they ship basically vanilla GNOME.

Your dconf key looks correct; now you need to enable the cap_sys_nice capability and next time you log in it should work.

[chocolate]

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.

That's nice.
Short of analysing source code and Git logs, I don't know how to move from here, given the... undocumented state of this feature, so I hope I'm not bothering you by asking this.
Do you happen to know which GNOME Shell version started supporting this, and if this is a feature that has to be enabled at compile time? I suppose if it's not enabled at compile time, then some distributions might not have it in their shipped binary.

Also, what is displayed at /org/gnome/mutter/experimental-features in the "Custom value" box in dconf Editor? Mine shows

['rt-scheduler']

which should be fine, given the type is "String array".

Edit: found the relevant commit that adds information to the dconf XML.

https://gitlab.gnome.org/GNOME/mutter/commit/dae2c1d420ed272710ac55b7a00f6787e5c0e762

It was committed 10 months ago, so it seems to be present in a stable version starting with GNOME 3.34.

[chocolate]

Ugh, this thread is getting out of hand...
[...]
chocolate
[...]

Excuse me? I explicitly stated how I find both your contributions to these forums, and those of others, useful. I don't see how I can be called out as a fanboy of anything in particular, given my interests reach any and all technologies found on a desktop or embedded GNU/Linux system, including various DEs and WMs (no matter which I prefer for a particular purpose).
I simply didn't find your counter-crusade valid given I don't see any crusade moved against anyone in the first place. I only see some strongly opinionated people venting their frustrations, which is perfectly fine, although the bulk of the discussion could be moved to a dedicated X.Org & Wayland topic.
I come here to hopefully learn something new each time.

[oiaohm]

The mandatory CSD thingy is just blowing my mind... How dare you assume all clients will use CSD!

You have a problem here. You have not worked out that Microsoft Windows is in fact CSD. That right windows is client side decorations done by the toolkit of windows. This is why applications can simply splice in buttons into the window bar if they want it. Server side decorated you cannot in fact do that splice into window bar.

- No consistency, ever. Windows and X11 got it right.

So this is not right because CSD is how Microsoft Windows works the thing is most applications are either using the single toolkit windows provides or there toolkit is copying the windows settings you do see odd applications like winamp that went stuff it under windows as well. X11 also has problem that application cannot always tell when windows manager will be doing server side decoration so you can end up with doubled or none at times.

- The Qt default skin is total crap and its CSD-style title bars look like somebody made it in 1 minute! Like no dedication to it...

That default skin in fact turns up under windows with Qt applications from time to time when someone builds Qt by mistake without the Windows platform appearance integration stuff.

- XWayland apps do have window decorations... So why not the rest!!!

That is not always true. Think XMMS it is client side decorations under X11 and its not the only one. So the reality with Xwayland or bare metal X11 server is you need both client side and server side decorations.

-Yeah! Weston running Weston application and GNOME application and Enlightenment application with the GNOME border and Qt application with the most horrible borders ever! So many window decoration styles at the same time!
Isn't that annoying?

Yes it annoying and the problem will not be solved by server side decorations alone we need more unity in themeing across the complete desktop like it or not client side decorations are here to stay on X11 desktop and wayland..

Power users want to script the desktop.

This is true but you have missed physically handy-caped need to script their desktop. This is not want this is if they cannot they cannot use the desktop at all.

They can't under Wayland. They say AT-SPI2 is the solution, but....

Drop this but. The reality is AT-SPI2 is the interface for the physically handy-caped if there is anything a power user wants todo scripting their interface it needs to work though this for the physically handy-caped. Why should wayland have a interface for power users that results in the physically handy-caped being left high and dry without the features they need.

And about screen recording, they say PipeWire will do, but I sort of feel PipeWire will be so heavy on resources...

This is not in fact true. PipeWire screen capture with wayland is lighter than screen capture with X11 server. Because you can use the direct drm layer so use the gpu cards onboard encoder or other methods to avoid massive load.

The lack of a wlrandr-like thing prevents the user from creating new modes or switching them from the command line (or a script).
They say that a viewport protocol will fix the issues BUT that won't change the fact I still cannot create new modes or change the resolution with a single command that would work on all desktops!

This is you ignoring problem of modern day hardware. In fact not that modern. Some of the early LCD screen did not have scaling either. So of cost cutting that appears in some Hidpi monitors/tv is limited scaling modes. So directly control screen is no longer such a hot idea. You need a man in the middle to go is the request with this screen sane. If your request is going to end up with a 1 inch image in the center of you screen that you cannot really use you don't want it to happen.

The reality is the GPU is just as capable if not more capable at scaling image than the scale chip that might be built into the monitor. Please note I worse scale chip that might be built into monitor not all monitors are capable of scaling anything.

Plus, what about changing refresh rates? Yeah, sometimes I want to play my Turrican but I have to set the rate to 50Hz for it too look perfect! Can't I do that?!

This is your again being simple minded. This is what "Variable Refresh Rate Support" is about doing better. Lets say you are playing Turrican at 50Hz you puase and now want to play a youtube video that is at 30 frame per second to get some game hints. Setting one refresh rate really does not work well. GPU are also these days able to fake this fairly well when you have a monitor that does not support particular refresh rate well.

Changing refresh rate to a per application thing instead of global thing is the way forwards like it or not.

Lot of these old ways of doing things going forwards are just straight wrong for the future.

And the fact that XWayland has a freaking "refresh rate" that isn't even synchronized to the vertical blank makes things worse. Couldn't they just update clients whenever they are done drawing?! More so for OpenGL/Vulkan/whatever clients! Instead of "polling", why not update when they request a buffer swap!!!
I mean this is a horribly stupid idea that apparently nobody will ever fix...

Everything you just stated here is because XWayland is in fact conforming to X11 protocol specification.

[oiaohm]

Let me break the news to you - world did not start with Linux, KDE or Gnome. And nobody will care about these Wayland/X11 discussions in 10 years. Maybe as a historical curiosity, how X11 was well developed, has spread to all Unix workstations in a couple of years, and continued to be used for 33 years (and counting). And how and why Wayland was still not widely adopted 11 years after initial release.

There are a few key differences. X11 did not have strong incumbent to replace in the Unix world. Also your couple of years claims is also wrong SGI only made their first X11 server in 1991 before that on their Unix they were running their own unique graphical environment and they were not one in the Unix Workstation space doing this so it takes in fact from 1987-1991 for X11 protocol to get full penetration on the Unix workstation so roughly 14 years with out a strong functional incumbent. X11R5 was a major turning point in X11 history will go into that latter.

Basically 11 years is still less than the time it took X11 protocol to get proper adoption.

In 1990, we were programming on X11 using different toolkits, Athena, OpenLook, Motif. We had cut and paste among different toolkits, which used ICCCM.
You can read Motif documentation from the 1993 about how it is done. For simple text based exchange, toolkit handles cut and paste on all relevant widgets.

Did you not read link X11R5 that is September 1991. X11R4 that Motif version of cut/copy/paste is in fact differently implemented.

Just because you are using ICCCM does not it worked all the time. XtSetLanguageProc() bit of X11R5 allows programs to in fact get what the text on the clipboard was encoded in. Great fun X11R4 and before you had pray that all application were putting the same encoding into the ICCCM clipboard or very strange things could happen that are perfectly legal in X11R4 and before. This is one of the reasons why there were many workstation clipboards. I was working across multi different Unix workstations back then. I am more than aware of the glitches here and how many different workstation environments there were.

X11R5 changes is when you see almost all the Unix unique graphical environments die before that X11 protocol was just one of many, The only real ones stubborn past 1991 in the Unix world was NeXTSTEP that comes OS X and BeOS that mostly dies. By the time Linux is looking for a Graphical environment the X11 or bust mostly.

Its really simple to forget all the ones that died. It also really simple to miss the when and why. Clipboard in fact works at least somewhat dependable turns out to be one of the reasons why all the different Unix graphical stuffed died in 1991. Was not perfect and was not officially mandated to be implemented in the standard until well latter.

Out of curiosity, I have tried Wayland on my development machine, that is OpenSuSE 15.0. I can't use the latest release, since I have real customers who rely on binary compatibility of my software.
Anyhow, somewhat predictably, Wayland immediately crashes the computer, I had to do a hard reset.

https://forum.kde.org/viewtopic.php?f=66&t=156354

Back to X11, I have work to do.

Really that is using Nvidia I am sorry back in year 2000 Nvidia was giving me the same trouble with X11 to the point I had to use a S3 card back then with no opengl acceleration at all. Sorry it is the Nvidia driver blame in this case the open source one nouveau.noaccel=1 works around it because you are not using the GPU. The bug you are refering there is from 2018 and has been addressed.

https://www.phoronix.com/scan.php?page=news_item&px=EGLStreams-Merged-KWin-5.16

You got to be able to use the Nvidia closed source drivers in 2019 that also show hey that broken open source Nvidia driver not kde code problem.

Realy like it or not dpeterc you are being unfair you have missed that it took X11 14 years to get full penetration and been in enough of a usable state that those making their own interfaces for X11 were willing to give them up. Why should we not expect 14 years of resistance from X11 against wayland this would be being fair.

[tildearrow]

Ugh, this thread is getting out of hand...

Like I thought they would have Wayland ready in a few years from previous experience...
...but it's been years and it is barely beginning to gain traction!

And we still fight about simple things that are wrong with the protocol instead of doing something to fix it!
And then 144Hz comes and makes the thread even worse with his stupid pro-GNOME propaganda he scatters all over the forum like perennial rain!

You know, the reason why I originally blanked 144Hz's post is because his trolling is getting out of hand. It was a massive insult to the other desktops to be saying this kind of stuff!!:

Mutter devs are a BIG part of the Wayland Meritocracy. Don’t like that? Then GTFO.

Technically saying "GNOME rules the world! Be our slaves or die in a fire!"
Like, WHAT?! Sorry, yeah, I know it was a horrible idea to blank his post but I just could not take this massive insult towards other desktops that tells us that GNOME is the right way.
Come on! Look at their atrocious decisions! You think this is the way to go?!:

There are no plans to support server side decorations under Wayland, and it'd be a step backward from the path we are aiming for with Wayland. So given that, I'm going to close this one as a wont-fix.

Really?... REALLY?! Why in the world would that be a "step back"?! Why! That makes absolutely no sense!
And it just looks like you don't want to implement that, ever, because everyone has disliked your response (yeah), and even after a long debate you cannot change your mind!

I mean, Wayland has been a sort of disaster from the start.
The mandatory CSD thingy is just blowing my mind... How dare you assume all clients will use CSD!
Seriously, this is a big problem, because:
- No consistency, ever. Windows and X11 got it right.
- The Qt default skin is total crap and its CSD-style title bars look like somebody made it in 1 minute! Like no dedication to it...
- XWayland apps do have window decorations... So why not the rest!!!

Look at this mess!



Yeah! Weston running Weston application and GNOME application and Enlightenment application with the GNOME border and Qt application with the most horrible borders ever! So many window decoration styles at the same time!
Isn't that annoying?

The lack of data query (like screen recording or xdotool-like operations) is a big problem too!
Gamers want to use Wayland.
Power users want to script the desktop.

They can't under Wayland. They say AT-SPI2 is the solution, but...

And about screen recording, they say PipeWire will do, but I sort of feel PipeWire will be so heavy on resources...

The lack of a wlrandr-like thing prevents the user from creating new modes or switching them from the command line (or a script).
They say that a viewport protocol will fix the issues BUT that won't change the fact I still cannot create new modes or change the resolution with a single command that would work on all desktops!

Plus, what about changing refresh rates? Yeah, sometimes I want to play my Turrican but I have to set the rate to 50Hz for it too look perfect! Can't I do that?!

And the fact that XWayland has a freaking "refresh rate" that isn't even synchronized to the vertical blank makes things worse. Couldn't they just update clients whenever they are done drawing?! More so for OpenGL/Vulkan/whatever clients! Instead of "polling", why not update when they request a buffer swap!!!
I mean this is a horribly stupid idea that apparently nobody will ever fix...

Sadly, as long as 144Hz's crusade remains active and developers refuse to implement crucial things Wayland will never be ready.
We will be stuck in the same arguments, fighting without reaching an agreement, for years to come.

144Hz - uid313 - intelfx - chocolate

And as long as the fanboys keep saying "no no no Wayland is always best blah blah" and making fun of the ones who really want to point the issues out, Wayland will be a discussion hell.

Enough said, I am out of this thread! Too much fighting.

[chocolate]

Hurd is political.

I'm sorry to go OT, but I can't let this pass. GNU Hurd by itself is not political at all, even if being aligned with GNU makes it obviously inherit a certain vision.
It's quite interesting from a technical point of view, more so than any, or at least most, other "hobby" projects. Its developers don't seem to be at all delusional about its practical usage in the short or long term. In fact, there's no "official" GNU stance recommending against Linux in favor of Hurd, quite the contrary.
You just used it to reinforce your point that political projects remain unsuccessful. This is also in antithesis with the fact that Hurd is already a success just by virtue of its original design goals and the research around them.

[dpeterc]

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.



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.



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.

I would like to respond, but I find it hard to pinpoint a thought worth arguing with in your post.
Let me break the news to you - world did not start with Linux, KDE or Gnome. And nobody will care about these Wayland/X11 discussions in 10 years. Maybe as a historical curiosity, how X11 was well developed, has spread to all Unix workstations in a couple of years, and continued to be used for 33 years (and counting). And how and why Wayland was still not widely adopted 11 years after initial release.
In 1990, we were programming on X11 using different toolkits, Athena, OpenLook, Motif. We had cut and paste among different toolkits, which used ICCCM.
You can read Motif documentation from the 1993 about how it is done. For simple text based exchange, toolkit handles cut and paste on all relevant widgets.

http://www.linux-france.org/article/motif/oreilly/Vol6a_html/ch17.html

Out of curiosity, I have tried Wayland on my development machine, that is OpenSuSE 15.0. I can't use the latest release, since I have real customers who rely on binary compatibility of my software.
Anyhow, somewhat predictably, Wayland immediately crashes the computer, I had to do a hard reset.

https://forum.kde.org/viewtopic.php?f=66&t=156354

Back to X11, I have work to do.