No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by angrypie View Post
    Are you doing self-parody now?
    Like all trolls are during this time, being masters at social distancing, is he living it out in the basement.


    • #32
      Wonder how long NVIDIA is going to keep pulling this tantrum fit over their attempt to make EGLStreams the standard or whatever it was. I hope AMD's next cards are going to be competitive with NVIDIA's 30 series!


      • #33
        Originally posted by tildearrow View Post
        Where is my wlrandr?
        Not coming been done a different way.

        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.

        Originally posted by tildearrow View Post
        My wdotool?
        Wayland capture? (let me propose a name: wsnoop)
        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.

        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.

        Originally posted by tildearrow View Post
        A standard non-GNOME-specific way to have clipboard?
        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.

        Originally posted by tildearrow View Post
        SSD for Wayland apps?
        I guess you mean server side decorations Wayland protocol support that and it implemented in GTK/QT.

        Originally posted by treba View Post
        Where is my font rendering?
        The font server and font rendering disappeared out of x11 server ages ago.

        Originally posted by treba View Post
        My Wprint? Seriously, Wayland can't do fax?
        Same with the X11 print server has been no more for years..

        Originally posted by treba View Post
        My primitive rendering?
        Need more clarification on this. Because wayland does not have a lot of primitve rendering when this is basically duplication with opengl and vulkan rendering that in fact work out to use GPU more effectively than what X11 primitive rendering did.

        So from both of you I really did not see stuff that is not covered these days. Some ares need to complete more like AT-SPI2 mouse issues. This is getting really close to done.


        • #34
          Originally posted by gufide View Post

          For server side decoration, there is an xdg protocol for that. wlroots and kwin-wayland implements it. GNOME deliberately refused to implement the protocol because they prefer all clients to render their own decorations.

          Screen capture works in wayland using pipewire or via KMS directly.
          You say deliverately like it's some evil thing. It's not, not having the compositor deal with decoration makes the compositor design much simpler and is one of the reasons why Mutter is far ahead on the Wayland route.

          Weston and Mutter both have compositor designs that make it near impossible for them to render around the application without large caveats, you'd have to start messing with subsurfaces around the window surface, designate a client that would render to those subsurfaces and then you'd to deal with resizing them all at the same time without flickering.

          Mutters compositor is "dumb" when it comes to clients, it composites surfaces, not much else.
          Last edited by Britoid; 30 March 2020, 07:08 PM.


          • #35
            Originally posted by 144Hz View Post
            Mutter devs are a BIG part of the Wayland Meritocracy. Don’t like that? Then GTFO.
            You make me feel embarrased to be a GNOME user.


            • #36
              Originally posted by oiaohm View Post
              I forgot an [/ironie] tag

              As a friendly reminder to those who want to stick with Xorg: at some point you'll need to help maintaining it, let alone adding new features - many of the current devs will mostly care about Xwayland and new hardware features will simply not be supported (or are already - e.g. hardware overlays). But I'm sure many of those experts here that are totally informed about the technical aspects of these topics will have no problem doing so


              • #37
                Phoronix can you please make the comment section tree-like so that I can easier enjoy all these flame wars?
                And besides "Like" please also add "Slap in the face" and "Kick in the ass".
                Thank you.


                • #38
                  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


                  • #39
                    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; 30 March 2020, 07:52 PM.


                    • #40
                      Originally posted by pieman
                      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."
                      Here is a good discussion about the topic I found: What are the requests, events etc VRR needs for the...

                      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.