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

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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!

[oiaohm]

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!

Those who did litestep and other shell for windows found out that Windows is in fact CSD. What thread do you think windows decorations are in fact draw in under MS windows. The answer is like it or not the applications thread. The decorations are not drawn by the ms windows kernel services this is where ms windows graphical servers live. The windows decorations are not drawn by the MS Windows shell either. This is a fairly simple process of elimination. If the client side decorations are not draw in either of those locations you are in fact looking at Client side decorations like it or not. When you hack those decorations this is party why uxtheme under windows could be so dangerous you are in fact running that modification at the authority of the application.

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.!

Get this into your mind there is no such thing as Server Side Decorations under MS Windows. Server Side Decoration does not exist on MS windows and never has. MS Windows has always used platform toolkit decorations so they are generated from the client thread there is no server doing decorations.

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.

The point you miss here that is very critical. You have GTK skinning to look like windows and QT skinning to look like windows. Ok can GTK skin it self to like like Qt and the reverse?

https://en.wikipedia.org/wiki/QGtkStyle

The answer is yes it possible.

Under Wayland, due to this CSD crap, some applications look like GNOME/KDE/whatever and some others do not.
But at least it's still using SSD! It is being decorated by the system, unlike in Wayland.

This is you being stubborn there are two ways to skin this cat.
1) SSD
2) A single core theme agreed on that everyone uses(this is MS Windows)

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.

SSD does not fix the Appimage problems. Yes it fixes the windows boarders it does not fix the toolbar colours and so on. The method MS windows uses would fix it all. CSD is not the problem. Not having a single core core toolkit or single agreed theming system is the problem.

CSD only just makes the issue more in the face.

...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)

To be horrible lot of games do go out of their way to make their own decorations these days to make their games more unique and their manuals more constant. This problem would be solved if there was a single universal tookit just as much as SSD. In fact that single univerisal toolkit fixes more problesm.

Add them to the list as well. Look. The data query protocol must be generic, and cover most use-cases, accessibility included.

No this is you being a moron. If the generic data query protocol could do it all at-spi2 would not exist. What is the key thing missing from the generic data query protocols under X11 a very important for the physically handy-caped is application state. A physically handy-caped may do the same button/action and depending on what state the application what that action in fact does.

Basically you are telling physically handy-caped in this case to use something that is absolutely useless to them. at-spi2 can do all the power users want and more. That application state information makes it a lot more simple to automate applications with 100 percent dependability something the generic options do not give.

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.

No this is your ignoring the other problem.

This may be a niche but how come Windows still supports it?

Not really.

https://www.pcgamesn.com/amd/integer-scaling-how-to

Recent years we have seen GPU pick up the scaling because modern day monitors cannot always do it. So in theses setups you have the monitor running at 4K for example but you have switched the desktop back to some lower resolution for game then gpu to upscale? Does this really make sense. Why not leave the monitor at 4K for the desktop and just upscale that 1 application.

Changing complete screen resultion on a monitor that cannot scale and then using the GPU to scale any how does not make much sense.

Basically this problem need to be balanced. We are needing something to make choices based on connected monitor and GPU how a screen size request is in fact handled. Is it scaled in the GPU or do we change the monitors resolution. Of course this opens up the possibility of the mixed scale up application and leave desktop resolution alone.

The problem space here is more complex than it use to be because monitors that could not scale were rare but these days they are coming common.

Your CRT monitor will not last forever. What are you going todo when the time comes to replace the CRT and you cannot get a monitor that can scale. So you have to use GPU scaling.

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

VRR shell means playing windowed it can in fact work as the system can balance out the frame rate base on what is changing on screen..

Just like GPU can do scaling in GPU for monitor that does not have scaling. GPU can also do VRR on a monitor that does not support VRR why would you do this power saving by reducing the number of buffer switches you have todo.

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.

That polling method is still what is written in the X11 protocol for how it meant to be done. Thinking that section of the X11 protocol was written before we had GPUs and computers were not processing fast enough to make the stuttering problem it was basically ignored bug in protocol. Sometimes you don't want things implemented how the X11 protocol says because if you do it total horrible. So the way Arcan and XMir does it is technically wrong by the X11 protocol.

https://www.phoronix.com/scan.php?page=news_item&px=XWayland-Multi-Buffering-Lands

There was start to a complete fix land in 2019 yes this is doing something the X11 protocols says not to do. So yes now Xwayland is also technically wrong by the X11 protocol. One day someone might fix that section of the X11 protocol.