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

[arokh]

I never said it wasn't possible. I said it didn't exist, and it still doesn't, unless you consider the hack described above as a solution.

Actually you did, but feel free to deny it all you want. I consider the solution above a solution, yes. There are other solutions to it as well, but it's clear that you're not actually looking for one.

Didn't know GNOME was accepting new features. 2020 is a truly a fucking mess.

Ok.

I don't need feelings to write text on a screen. You talk like a wuss.

Thanks for clearly showing that you're a complete idiot.

[angrypie]

You said it's not possible, not my problem that you'd rather spend your time trolling than actually building it.

I never said it wasn't possible. I said it didn't exist, and it still doesn't, unless you consider the hack described above as a solution.

Didn't know GNOME was accepting new features. 2020 is a truly a fucking mess.

Did you feel smart when you wrote this?

I don't need feelings to write text on a screen. You talk like a wuss.

[arokh]

The Wayland color picker function was merged 4 months ago, and the latest stable release of gcolor3 was more than one year ago, which means you have to build it from source to get that function.

You said it's not possible, not my problem that you'd rather spend your time trolling than actually building it.

Yeah, fifteen fucking years to implement a color picker. Remember that next time someone mocks Microsoft for getting virtual desktops in 2015.

Couldn't care less about that. Did you feel smart when you wrote this?

[oiaohm]

The Wayland color picker function was merged 4 months ago, and the latest stable release of gcolor3 was more than one year ago, which means you have to build it from source to get that function.

Yeah, fifteen fucking years to implement a color picker. Remember that next time someone mocks Microsoft for getting virtual desktops in 2015.

Virtual desktops appeared in the Unix X11 world in the 1980s. Took Microsoft 25+ years to get that. So if you are using Microsoft virtual desktop as the tolerable limit for how long you have to wait for a feature you have at least another 10 more years before you can complain at least. CDE if I am being nicer the 1993 default Unix desktop had virtual desktop because the prior stuff did even taking that date ie 2015-1993 gives you 22 years delay on getting the feature so still at least another 5 more years before you can complain.

Really bring Microsoft in with features really says you need to give wayland more time because it took Microsoft ages to provide particular features. Virtual desktops were on windows by third party hacks way sooner and the Wayland color picker status lines up with that.

Wayland core protocols still cannot do color picker. That implementation is using libportal from flatpak todo it. It also possible to-do color picker by AT-SPI2 as well. Its also possible using Wayland unstable non mainline protocols screencopy todo colour picker that implements are debating about for the past 10 years. Its also possible todo it using pipewire.

Its not that there have not been color pickers under wayland there are still just too many ways to implement color picker at this stage and lack of solid agreement on how it should be. Please note X11 server has even more ways to implement color picker this is something that been lacking a solid agreement on how for a long time.

By the way there are 22 different ways to implement color picker under MS Windows as well. The lack of solid how its not X11/Wayland unique problem.

[angrypie]

Oh look, another raging troll spreading FUD...

https://github.com/Hjdskes/gcolor3

The Wayland color picker function was merged 4 months ago, and the latest stable release of gcolor3 was more than one year ago, which means you have to build it from source to get that function.

Yeah, fifteen fucking years to implement a color picker. Remember that next time someone mocks Microsoft for getting virtual desktops in 2015.

[arokh]

You can't use a color picker (a Windows 1.0 feature) under Wayland. So fucking modern.

Oh look, another raging troll spreading FUD...

https://github.com/Hjdskes/gcolor3

[angrypie]

It's done properly now and we've got a modern, fast and secure desktop.

You can't use a color picker (a Windows 1.0 feature) under Wayland. So fucking modern.

[Azrael5]

The games use X11. XWayland is used to run them on the Wayland session.

I wish Michael could test with Wayland-native games...

So the comparison is a waste of time. Indeed he is comparing xorg games with xorg games.

[arokh]

Do you deny that -ALL- wayland compositors have unusble input lag?

Denied. Using the "run-ahead" feature of RetroArch running on Sway/Wayland shows that input-lag is non-existant. You are in fact incorrect.

Do you deny that wayland has been in development for nearly 15 years and it is still alpha quality at best?

Denied, I'd say it's close to production quality already with the right hardware.

Do you deny that waylands "lowest common denominator" approach has caused the reinvention of almost all concepts desktops need? Minimize, fullscreen, resolution changing, variable refresh, system tray, clipboard, desktop sharing and even sync output on input, all of these things have been implemented, but took this long.

-Not 1 year, but 15 years- 15 YEARS!! Too fucking long and it's asinine.

It's done properly now and we've got a modern, fast and secure desktop. You can either wake up or remain in the past with your legacy software.

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