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

[oiaohm]

What? Facts like, input lag on wayland makes it unusable in most desktop usage scenarios....

This is horrible miss fact Wayland is not the problem there. X11 server and compositor also have their fair share of problems.
DRM leasing exist for a reason because X11 output lag from server cannot fixed. By design X11 server is always at least 1 frame behind on output.

https://keithp.com/blogs/DRM-lease/

https://gitlab.gnome.org/GNOME/mutter/issues/334

These bugs have been turn up in the last 12 months as we finally started getting optimised wayland compositors instead of Jerry rigged ones. This is where a person is using a desktop with pure wayland applications versions vs X11 application versions of the same programs we are now starting to see wayland promise of low input lag than X11 can do.

Of course is been very hard with a person running a X11 program inside xwayland and put its performance head to head with a X11 server run on bare metal Both of those have X11 server running so you would expect some overhead of the wayland layer but its getting close to zero as Xwayland gets better optimised.

So basically the arguement you are making the last 12 months is seeing turns upside down. Yes x.org X11 server is suffering from more high input lag issues than wayland compositors are at the moment.

wayland is such an incomplete protocol that compositors must reinvent basically every single wheel independently for each and every single one of them...

I wounder how many of these points you have wrong. Wayland protocol does not duplicate up what opengl/vulkan interface provide. X11 did. AT-SPI2 is a newer protocol than what X11 is as well. So you see X11 duplicating up AT-SPI2 interfaces. This is what you will find a lot of things that appear to be missing from wayland are in fact intentionally not in wayland because some other protocol does the job properly there is no need to second implement stuff worse.

Basically there is a long list of feature that appear to be missing from Wayland Protocol that once you look closer at what the other standards you should be using provide there is no point for Wayland Protocol to duplicate implement.

[duby229]

This is horrible miss fact Wayland is not the problem there. X11 server and compositor also have their fair share of problems.
DRM leasing exist for a reason because X11 output lag from server cannot fixed. By design X11 server is always at least 1 frame behind on output.

https://keithp.com/blogs/DRM-lease/

https://gitlab.gnome.org/GNOME/mutter/issues/334

These bugs have been turn up in the last 12 months as we finally started getting optimised wayland compositors instead of Jerry rigged ones. This is where a person is using a desktop with pure wayland applications versions vs X11 application versions of the same programs we are now starting to see wayland promise of low input lag than X11 can do.

Of course is been very hard with a person running a X11 program inside xwayland and put its performance head to head with a X11 server run on bare metal Both of those have X11 server running so you would expect some overhead of the wayland layer but its getting close to zero as Xwayland gets better optimised.

So basically the arguement you are making the last 12 months is seeing turns upside down. Yes x.org X11 server is suffering from more high input lag issues than wayland compositors are at the moment.



I wounder how many of these points you have wrong. Wayland protocol does not duplicate up what opengl/vulkan interface provide. X11 did. AT-SPI2 is a newer protocol than what X11 is as well. So you see X11 duplicating up AT-SPI2 interfaces. This is what you will find a lot of things that appear to be missing from wayland are in fact intentionally not in wayland because some other protocol does the job properly there is no need to second implement stuff worse.

Basically there is a long list of feature that appear to be missing from Wayland Protocol that once you look closer at what the other standards you should be using provide there is no point for Wayland Protocol to duplicate implement.

Asinine opinions of yours at best...

Do you deny that -ALL- wayland compositors have unusble input lag? Do you deny that wayland has been in development for nearly 15 years and it is still alpha quality at best? 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.

[tildearrow]

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

Did you just tell us that GNOME won and it should be the only desktop?!

It's enough. You are A FREAKING DISGRACE.

[tildearrow]

Not coming been done a different way.

https://bugzilla.redhat.com/show_bug.cgi?id=1289714

Wayland viewporter protocol. This allows application to ask for a full screen resultion that the monitor does not support and have the compositor decide if it scales, windows... Yes application does not need to be informed that this has happened behind it back either.

This is also designed to avoid mangling another applications applications output when you resize screen. Yes xrandr is starting to work in Xwayland with the wayland side done by Wayland viewporter.

Ugh come on... What about if I want to change my display resolution, screen orientation or position?

What a dumb idea :l

There are fairly much getting to the point of close to fully sorted out.

The path under wayland todo this is mostly AT-SPI2. This was a case we had a double up AT-SPI2 controls and X11 controls under X11 for remoting applications under Wayland we drop back to AT-SPI2. There are still a few bugs and issues in implementations being ironed out.

https://wiki.gnome.org/Accessibility/Wayland

Big thing is with the AT-SPI2 path is that approval can be done before tool is allowed to either inject keys or snoop so not security nightmares as the X11 stuff was.

Please note that is a GNOME-specific protocol. I am talking about a standard protocol in Wayland.

Couldn't they use a permission system, so that the user grants applications access to it?

X11 clipboard protocol is fragemented to hell there are in fact 12 different ways todo clipboard inside X11 with all different levels of compatibility wine project supports 8 of them. Lets just say this what you are talking about here is a X11 issue.

If you are writing pure wayland applicaiton you have a by standard wayland clipboard. Not a GNOME specific one in fact gnome applications directly running in Wayland are using this single standard so is your KDE ,qt .... In pure wayland applications for once we have zero clipboard design fragmentation.

I never knew there were that many clipboards...

I guess you mean server side decorations Wayland protocol support that and it implemented in GTK/QT.

Except that Mutter does not implement it as mentioned before in this thread.

The font server and font rendering disappeared out of x.org x11 server ages ago.

Same with the X11 x.org print server blah blah blah

Do you realize that treba is just making fun of me?

[tildearrow]

With X every program can capture every mouse/keyboard input and every video output.
Not with Wayland, that's why screen sharing needs a specific API with Wayland for instance.
In that way, Wayland is actually better and more secure.

The problem with Wayland data query:

	Is there a way to do data query? (e.g. retrieve window/screen/mouse/keyboard info)	Does the user have to grant permission for it?
X11	Yes	No
Wayland	No	No

So, the problem is: either everything or nothing.
In X11 you have data query (e.g. xdotool) but it is insecure because any application can access this info freely.
In Wayland there is no way to do data query (in the name of "security").

Why isn't there a solution like this?:

	Is there a way to do data query? (e.g. retrieve window/screen/mouse/keyboard info)	Does the user have to grant permission for it?
Wayland (let me propose a name: XDG-Query)	Yes	Yes

[oiaohm]

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

When it comes to the current gnome X11 compositor vs gnome wayland compositor when it comes to direct benchmarking of input lag there are ways todo this the wayland version wins more of that no. So of All wayland compositors have unusble input lag than gnome desktop be it on X11 or wayland complete unusable?

So from duby229 statements duby229 must believe gnome is not useable. Or has to admit that all compositors be it X11, Wayland, or window dwm have different levels of input lag issues and it normal compositors. There are a lot of wayland compositors at the moment that are head to head in performance with their X11 version.

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

Sorry you would not call wayland implementations Alpha quality at this point. They cross the standard to Beta quality quite a few years ago.

https://www.guru99.com/alpha-beta-testing-demystified.html

Basically you need to read up on what Beta means. Alpha a user cannot really use it in any form of production sense because it will crash them. Go get the reactos install image install it in a vm and run it for a while. if you can get more 2 days using it without it being stuffed up some how past all user-ablity. You are doing well this is Alpha software for you.

Weston has been Beta grade software from 1.0 release. So the question is has it moved from Beta to RC/Production grade. Wayland i getting fairly close to move out of Beta.

So basically another statement that is wrong and has never been true.

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.

Writing protocols, Implementing to test protocols. Getting feedback back on those protocols with lots of rinse and repeat is not fast process. Does the current X11 protocol have any concept of Minimize or fullscreen or system tray or clipboard or desktop sharing the correct is no it does not.

There is a stack of defacto standards that all this stuff under X11 is implemented by different parties differently. Yes those defacto standards have lead to wine having bugs submitted on a per windows manager base.

So I am not really sure where you are getting the lowest common denominator logic from the X11 standard is closer to lower common denominator standard than the wayland standard is like it or not. Remove the defacto standards from X11 desktops and you don't have a functional desktop. You can have a somewhat functional desktop using only wayland protocol and other formal standards like opengl/vulkan.

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

When the X11 protocol was 15 years old there was still no such thing as a clipboard or system tray, or ..... Taking 15 years to implement all this is still faster than the X11 protocol did it in. Heck there a lot in the wayland protocol that X11 protocol does not cover at all. It might be taking a long time to get the wayland standard written fully but its in a better location that you have a test suite and a standard where X11 you have a stack of mess with really nothing to say you implemented it correctly.

See the problem yet your arguments are not really based on the facts of the problem.

[duby229]

When it comes to the current gnome X11 compositor vs gnome wayland compositor when it comes to direct benchmarking of input lag there are ways todo this the wayland version wins more of that no. So of All wayland compositors have unusble input lag than gnome desktop be it on X11 or wayland complete unusable?

So from duby229 statements duby229 must believe gnome is not useable. Or has to admit that all compositors be it X11, Wayland, or window dwm have different levels of input lag issues and it normal compositors. There are a lot of wayland compositors at the moment that are head to head in performance with their X11 version.



Sorry you would not call wayland implementations Alpha quality at this point. They cross the standard to Beta quality quite a few years ago.

https://www.guru99.com/alpha-beta-te...mystified.html

Basically you need to read up on what Beta means. Alpha a user cannot really use it in any form of production sense because it will crash them. Go get the reactos install image install it in a vm and run it for a while. if you can get more 2 days using it without it being stuffed up some how past all user-ablity. You are doing well this is Alpha software for you.

Weston has been Beta grade software from 1.0 release. So the question is has it moved from Beta to RC/Production grade. Wayland i getting fairly close to move out of Beta.

So basically another statement that is wrong and has never been true.



Writing protocols, Implementing to test protocols. Getting feedback back on those protocols with lots of rinse and repeat is not fast process. Does the current X11 protocol have any concept of Minimize or fullscreen or system tray or clipboard or desktop sharing the correct is no it does not.

There is a stack of defacto standards that all this stuff under X11 is implemented by different parties differently. Yes those defacto standards have lead to wine having bugs submitted on a per windows manager base.

So I am not really sure where you are getting the lowest common denominator logic from the X11 standard is closer to lower common denominator standard than the wayland standard is like it or not. Remove the defacto standards from X11 desktops and you don't have a functional desktop. You can have a somewhat functional desktop using only wayland protocol and other formal standards like opengl/vulkan.



When the X11 protocol was 15 years old there was still no such thing as a clipboard or system tray, or ..... Taking 15 years to implement all this is still faster than the X11 protocol did it in. Heck there a lot in the wayland protocol that X11 protocol does not cover at all. It might be taking a long time to get the wayland standard written fully but its in a better location that you have a test suite and a standard where X11 you have a stack of mess with really nothing to say you implemented it correctly.

See the problem yet your arguments are not really based on the facts of the problem.

Another wall of bullshit from you.

Fact is Gnome with wayland only just became useful between 1-2 years ago and still took it well over a -DECADE- to get there. Fact is that even still to this day if you do anything moderately CPU intensive on -ANY- wayland compositor, including gnome, input lag becomes totally unusable even still to this very day. Fact is the wayland desktop experience is still so incomplete that it can -ONLY- be used up till the point you need a feature it doesn't have implemented yet. Fact is Hogsberg himself invented the term for wayland "lowest common denominator", I simply reused his asinine remark. Fact is when X11 was exactly as old as wayland is -RIGHT NOW- xorg was already forked from xfree86 and heavily developed. Fact is when X11 was 15 years old it was 2003 and desktop linux was at a marketshare height it hasn't reached before or since....

Need I keep going? I can keep laying facts down, this is just the simple truths whether you like them or not.

[oiaohm]

Ugh come on... What about if I want to change my display resolution, screen orientation or position?

What a dumb idea :l

Its not really a dumb idea its a different idea. Wayland viewporter protocol you can in fact ask for a orientation change on a per application base.

It leave it up to compositor if when you application asks for a different resolution if the compositor changes the display resolution or it simply scales the window. This is kind of better.

Think you have a application ask for 640x480 pixels that your monitor still supports xrandr changes to that only one problem your monitor happens to be hidpi and does not have scaling on that resolution. So now you have a small box in the centre of your screen and totally not usable as you cannot see the mouse pointer.

Really we need the means that Applications are disconnected from direct control over screen so some bit of software can use some smarts in the middle. On that screen wayland compositor could know that 640x480 is a resolution not to use so when application asks for that use scaling in the GPU so the screen output remains a usable size.

Wayland viewporter protocol is basically someone noticed there was a very nasty issue that xrandr could cause and that direct control of output from non approved applications need to go completely away.. Heck even with approved applications lot of cases there was logic the compositor would need to-do to keep machine use-able and not change to some non usable resolution at the same time letting the application work.

I never knew there were that many clipboards...

You think about the fun event when you have the clipboard data in each of the locations that your program knows about disagreeing with each other. At that point what data does the user in fact want to paste. X11 clipboard implementation mess is well beyond broken.

Except that Mutter does not implement it as mentioned before in this thread.

Depends on the version of Mutter some versions when you programs say I am server side decorations only Mutter does in fact do server side decorations because it has the code there for X11 windows. This is one of the recent changes in the last 12 months.

So if people push the point this feature could come normal in Mutter.

So, the problem is: either everything or nothing.
In X11 you have data query (e.g. xdotool) but it is insecure because any application can access this info freely.
In Wayland there is no way to do data query (in the name of "security").

You never asked yourself the right question should it be in the X11 protocol and is it even required in X11 or is it in fact duplication of something else.

[QUOTE=tildearrow;n1168935]Is there a way to do data query? (e.g. retrieve window/screen/mouse/keyboard info)[/QUOTE

Lets add to that question is there a way to get that information is a X11/Wayland neutral way. The answer is yes.

https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/

Basically you are ignoring the AT-SPI2 protocol. If application does not work with AT-SPI2 people with disability could have problems using the program this include compositors.

Please note that is a GNOME-specific protocol. I am talking about a standard protocol in Wayland.

What I pointed to was not a GNOME specific protocol but the Gnome site detailing how their implementation of AT-SPI2 under Wayland is going.

Couldn't they use a permission system, so that the user grants applications access to it?

AT-SPI2 go though dbus and it normal policykit permission system.

This is case where you need to explain why does wayland need to implement something that AT-SPI2 covers. Remember AT-SPI2 is something all compositors should support does not matter if they are x11 or wayland or something else on Linux.

What you are suggesting is in fact compositors implement this feature twice ones for wayland protocol and once for AT-SPI2 support that does not make sense really.

What you are asking for you should be up the ribs of wayland compositors to be AT-SPI2 compatible.

[Mario Junior]

Why? I just played Wolfenstein New Order & Old Blood using xwayland and had zero issues with it (Intel GPU). It's not Wayland that's crap, it's NVidia. If you want to play games on Linux, buy hardware that provides proper drivers for it and you won't have problems.

Why? https://www.phoronix.com/forums/foru...35#post1168835

Also, what else makes you assume that I use an Nvidia GPU? 🤨

[jacob]

Why? https://www.phoronix.com/forums/foru...35#post1168835

Also, what else makes you assume that I use an Nvidia GPU? 🤨

There is no stuttering or cursor lag here. As for why I assumed you use Nvidia, well that's because it's always Nvidia that causes issues with graphics on Linux (especially with Wayland of course, but not only). Intel and AMD GPUs just work as expected.