Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    wayland doesn't support freesync yet. big let down. and if something like VRR is going to be left to every single DE / compositor to implement then its going to make it hell. gnome will probably never adopt it as for similar reasons why they killed the minimize button and system tray. doesn't fit into the "gnome experience and philosophy."

    i wonder when xfce will get wayland support. gnome is way to big in wayland development and we need a lot more diversity in this regard. hows kde's wayland support?
    Last edited by pieman; 03-30-2020, 07:20 PM.

    Comment


    • #42
      Originally posted by duby229 View Post
      Which is exactly what's currently happening. Bye, bye.... Duh. As soon as a viable alternative to wayland becomes prominent then wayland will die. It's already inevitable -BECAUSE- it's too big a part of Gnome's asinine meritocracy.
      Viable alternative to Wayland? These Wayland hating Phoronix trolls are like flat-earthers, they really just give a flying fudge about facts

      Comment


      • #43
        Originally posted by arokh View Post

        Viable alternative to Wayland? These Wayland hating Phoronix trolls are like flat-earthers, they really just give a flying fudge about facts
        What? Facts like, input lag on wayland makes it unusable in most desktop usage scenarios and it's ubiquitous across every single compositor.... Or do you mean other facts like, Wayland has been in development for nearly 15 years and it is still alpha quality at best in every single compositor that exists.... Or do you mean facts like, wayland is such an incomplete protocol that compositors must reinvent basically every single wheel independently for each and every single one of them.... Waylands "lowest common denominator" approach is -WAAAAAY- too low. I mean for fucks sake it can tell you where the mouse is, but is completely incapable of syncing output on input.

        And most important of all lets not forget that waaay over a decade ago Hogsberg himself specifically stated that wayland was -never- intended to replace a desktop display server. It was entirely intended for incredibly simple IoT devices. The protocol simply doesn't do most of what a desktop compositor needs a display protocol to do.

        I mean really, what facts are you talking about?
        Last edited by duby229; 03-30-2020, 07:52 PM.

        Comment


        • #44
          Originally posted by pieman View Post
          wayland doesn't support freesync yet. big let down. and if something like VRR is going to be left to every single DE / compositor to implement then its going to make it hell. gnome will probably never adopt it as for similar reasons why they killed the minimize button and system tray. doesn't fit into the "gnome experience and philosophy."
          https://gitlab.freedesktop.org/wayla...land/issues/84

          The problem is different to what you think it is. When it comes to applications using VRR they will basically use opengl/vulkan like they do now though the normal DRM(Direct rendering manager) under X11 with Wayland. No major differences.

          Its more tell compositor to switch in VRR mode because if GPU is not in VRR mode program cannot use VRR mode. If every compositor implemented a unique way for this not going to be disaster bad because application code does not need to be coded uniquely for this. Application could simply try to use VRR see by opengl/vulkan it not working and display message telling user to enable it. Ok not the most nice experience. We are not talking absolutely deal breaker or stacks of unique code in applications so it works.

          The reality with current wayland protocol VRR could work perfect if the compositor was rendering the screen in VRR mode so the application able to use opengl/vulkan instructions to the DRM to control it.

          There is another option is application wanting to use VRR in fact use DRM leasing to have the complete screen handed over to them when leased they have full control of the VRR setting but this would be horrible rough. This has to be done for VR headsets because compositor does get to be too much overhead. Yes VRR in DRM lease done under wayland for Virtual Really works perfectly. So some VRR stuff works with wayland.

          Comment


          • #45
            Originally posted by duby229 View Post
            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.

            Originally posted by duby229 View Post
            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.

            Comment


            • #46
              Originally posted by oiaohm View Post

              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.

              Comment


              • #47
                Originally posted by 144Hz View Post
                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.
                Last edited by tildearrow; 04-01-2020, 01:09 PM. Reason: fucking off

                Comment


                • #48
                  Originally posted by oiaohm View Post
                  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

                  Originally posted by oiaohm View Post
                  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?

                  Originally posted by oiaohm View Post
                  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...

                  Originally posted by oiaohm View Post
                  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.

                  Originally posted by oiaohm View Post
                  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?

                  Comment


                  • #49
                    Originally posted by wagaf View Post

                    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

                    Comment


                    • #50
                      Originally posted by duby229 View Post
                      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.

                      Originally posted by duby229 View Post
                      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-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.

                      Originally posted by duby229 View Post
                      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.

                      Originally posted by duby229 View Post
                      -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.

                      Comment

                      Working...
                      X