Announcement

Collapse
No announcement yet.

X.Org vs. Wayland Browser Performance With Firefox + Chrome

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

  • #41
    Originally posted by bug77 View Post

    One thing: a decade after its inception, it still does nothing for performance. So far it only fixes security issues never documented to cause something significant in the wild (still welcome, as is any security fix) and does away with being able to run the same across GPUs (not Wayland's fault, but that's where it got us).

    Fwiw, systemd is 2 years younger and has already achieved a lot more.
    The security concerns are real, and not to abuse current events, but sometimes does it need a disaster before the need for more security becomes evident. Until such an event happens is a need not self-evident, because smart people know it cannot simply be implied solely out of fear and statistics. However, this doesn't automatically mean Wayland fits the shoe when the time comes, because we already know it didn't provide the promised performance benefits. So nobody is going to be dumb enough to put money on its promises on more security. Chances are that it's going to be another disappointment. Its lack of a wide-spread adoption means that it hasn't seen much exposure to risk, leaving room for a fair amount of worries, and... if it fails do we also know that we could have seen it coming. Who besides nerds wants this on their desktop?

    Most users are happy with X11 and distros simply turn off TCP/IP connections to the X server. That's enough to give users enough security. All other risks here imply that an attacker has gained access to the machine, which means there is much more exposed than a user's window content, key presses and mouse clicks. The later however seems to find most traction with users who know nothing about the underlying system.

    Comment


    • #42
      Originally posted by duby229 View Post

      I'm positive for sure. Most of the major distro's seem to have mitigated input lag somewhat by implementing (cgroup) rules to give Wayland maximum CPU under load conditions. But that's not a fix. That doesn't fix the input lag. It just brute forces past it.
      I don't see any Wayland process running, so whatever got this CPU time it wasn't Wayland. I can be wrong of course, but I doubt. You're probably talking about some temporary hacks like giving more CPU power to compositor or something.
      Last edited by Volta; 10 April 2020, 01:41 PM.

      Comment


      • #43
        Originally posted by bug77 View Post

        I don't think he's trolling. X is constantly getting bashed because it's bloated, outdated and such. And yet, you remove X out of the equation, insert the new, modern solution and performance barely moves. It's obvious something doesn't add up.
        It doesn't add up if you think everything that matters in this world is raw performance. Do you understand how many hacks have been done on Xorg to support compositing decently? And how many years it needed to mature? Were you a Linux user in the age of Compiz and Beryl? Keep in mind Wayland was envisioned back when DRI didn't exist IIRC (i am sure it was before DRI2, don't remember if it was before DRI as well).

        Comment


        • #44
          Originally posted by sdack View Post
          Most users are happy with X11 and distros simply turn off TCP/IP connections to the X server. That's enough to give users enough security.
          Good luck with this legacy software. When are they planning to release the next version? Oh, it's maintenance only. X and security seems like contradictions and while you have nothing to prove against Wayland I recommend to stop spreading FUD. Wayland is much smoother right now, but it's window managers job to give you better performance.

          Comment


          • #45
            Wayland allows a compositor to start implementing things such as direct-scan out, which should allow a client to end up rendering directly to the KMS plane, avoiding any sort of display server or compositor.

            So input lag under Wayland once these features are implement will be less than it was under X. But yes, Mutter as a Wayland compositor has a huge sweath of issues, but they're not a problem with the Wayland protocol itself.

            Comment


            • #46
              Originally posted by duby229 View Post
              I'm positive for sure. Most of the major distro's seem to have mitigated input lag somewhat by implementing (cgroup) rules to give Wayland maximum CPU under load conditions. But that's not a fix. That doesn't fix the input lag. It just brute forces past it.
              Input lag can be measured dude, go ahead and do so or find something more useful to do with your time. Nobody is interested in your input lag delusions.

              Comment


              • #47
                Originally posted by arokh View Post

                Input lag can be measured dude, go ahead and do so or find something more useful to do with your time. Nobody is interested in your input lag delusions.
                Such lag is noticeable in Quake live on Steam running in XWayland, but it's probably mutter issue.

                Comment


                • #48
                  Originally posted by sdack View Post
                  Wayland is a disappointment and you keep making excuses for it.
                  Based on what? On tool-kits not having fully implemented Wayland protocol?

                  Comment


                  • #49
                    Originally posted by frank007 View Post
                    Don't drink before turning on your PC.
                    Maybe you should drink more before turning yours on, to understand parody.

                    Comment


                    • #50
                      ITT: Trolls who think a benchmark about one application with similar scores justify ostrich-like avoiding of decades of improvements in software architecture in computer science. As if the application being able to run on both stacks wouldn't interfere with it's ability to take advantage of the better platform. Portability is adjusting to the lowest common denominator, and the lowest common denominator is whatever X can deal with.

                      X is not scalable. It worked passably well when UIs revolved around line stippling and rectangle drawing, but now that applications are rendering their own surfaces with low-level graphics APIs, it gets in the way more than anything. It obstructs display advancements at every turn. We've tacked on extensions to try and help it deal with that. And we've done reasonably well. But that's just 3 decades of polishing a turd. It's shiny as fuck, now, but it's still a turd. Underneath that smooth, mirror-like reflection of your face it's still shit.

                      No one wants to maintain it. Hear that? Everyone who works on it hates it. It's already dead. The only work that goes into it is work that's forced (like for security reasons). The people who understand it don't want to put any more effort into it. If the writers and maintainers see it as a dead platform, the users either need to step up and maintain it themselves (unlikely, as competent graphics engineers are more interested in following the current progress than maintaining cruft that predates them) or deal with the reality that their product has already been end-of-lifed.

                      Comparing Wayland to X as if it's an actual competitor is foolish. The dead don't compete with the living. They just sit in the ground and rot. Yeah, we've still got a ways to go to feature parity. Track missing features and help fix bugs. Cooperate instead of dragging your feet. Don't blame the devs for not doing what you want when they know more about the tech stack than you do. In short: figure it out.

                      Comment

                      Working...
                      X