Announcement

Collapse
No announcement yet.

Geometric Picking Finally Lands In GNOME/Mutter 3.34 For Lowering CPU Usage

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

  • #31
    Originally posted by ernstp View Post

    Have you tried recent Ubuntu 18.04.3 with all the updates to Mesa and Xorg also? I use it every day at work, not really noticing any problems...
    No idea, i've given up a few months ago trying to use it on my laptop. My I5-6300U struggled with gnome, and even my Ryzen 5 3500U laptop showed animation stuttering and intensive resource usage. I now use XFCE on my laptop. with Xrandr scaling.

    Comment


    • #32
      Originally posted by 144Hz View Post
      Mutter is used on enterprise class distributions
      but it looks like stumbling block was endless os doing some non-enterprisy stuff

      Comment


      • #33
        Stupid question incoming. Can someone please explain what "color picking" actually is, and why does Mutter ever need to perform complex work, reading pixels from GPU and what-not, on such a common operation like cursor movement? I was under impression that specifically cursor rendering is considered so fast-path that modern GPUs tend to include special hardware like overlays to offload cursor rendering as much as possible; so what's wrong with Mutter?

        Disclaimer: I'm totally unfamiliar with any kind of graphics programming so I'm likely missing some crucial context and/or detail. ELI5, please.

        Comment


        • #34
          Wow, I really didn't expect that. I mean, Mutter devs have found reasons (some of which are probably very valid) to delay this MR for >1 year, so I basically gave up any hope to see this in Ubuntu 19.10. Now they merged this plus other important and long-standing performance work by van vugt literally hours (or minutes?) before the hard code freeze hits.

          I mean, I'm not complaining, in fact I'm very happy about this. But it really makes me wonder. At first they played it extremely safe and delayed things a lot ("let's see if that other change that we thought about a few months ago might fix the same issue in a different way and with more lines of code and then decide which solution to choose"), and now BAM they merge it and some other performance MRs at the last minute. :-) I always thought you move fast and (hopefully not, but possibly) break things right after releasing a stable version, not immediately before it.

          Thanks to everyone involved, including feaneron who came up with the other solution that, as I understand it, seemed nicer from a conceptual POV and (initially?) offered better support for some special cases, but is more convoluted and performs worse. I'm really looking forward to Ubuntu 19.10 / Gnome 3.34 now!

          Comment


          • #35
            144Hz disabling extension version checking seems like a bad idea now, although the move to systemd units means systemd will start up gnome shell without extensions if it crashes.

            Comment


            • #36
              Originally posted by 144Hz View Post
              So they decided not to regress.
              before or after mouse movement become jerky?

              Comment


              • #37
                10% of cpu usage only to move the mouse?? I can't get more than 1% if moving only the mouse with openbox, why that huge difference?

                Comment


                • #38
                  Originally posted by 144Hz View Post
                  Baguy This article is about 3.34. If you want to talk about 3.28 or older. Then you should go and comment on that old stuff.
                  I'm not going to argue further, but my original comment was about how it took gnome so long to get up to this point. I think that is well on-topic.

                  Comment


                  • #39
                    Originally posted by intelfx View Post
                    Stupid question incoming. Can someone please explain what "color picking" actually is, and why does Mutter ever need to perform complex work, reading pixels from GPU and what-not, on such a common operation like cursor movement? I was under impression that specifically cursor rendering is considered so fast-path that modern GPUs tend to include special hardware like overlays to offload cursor rendering as much as possible; so what's wrong with Mutter?

                    Disclaimer: I'm totally unfamiliar with any kind of graphics programming so I'm likely missing some crucial context and/or detail. ELI5, please.
                    Back in the days all windows were rectangular but now windows can have any shape in theory.
                    So when you click with your mouse on the screen you have to do some work to find out which window is there...

                    Now I think it's something like this, since they already have the graphics of the windows from the actual drawing-windows part, they...
                    • setup a special "image"
                    • paint each window from the back to the front on top of each other
                    • but not the contents but just the shape filled with a different color each
                    • read the pixel under the mouse and see what color that was
                    • look up which window they painted with that color
                    That solves some problems like testing for complex shapes and rounded corners etc.

                    Except for the benefits of _not_ doing this anymore mentioned in the article it should also save you some VRAM I guess?

                    Comment

                    Working...
                    X