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

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

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

    In addition to Mutter seeing today an important last minute performance fix for the NVIDIA proprietary driver, Mutter also saw a long-standing performance optimization finally land for GNOME 3.34 that benefits all hardware/drivers...

    http://www.phoronix.com/scan.php?pag...metric-Picking

  • ernstp
    replied
    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?

    Leave a comment:


  • Baguy
    replied
    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.

    Leave a comment:


  • trek
    replied
    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?

    Leave a comment:


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

    Leave a comment:


  • 144Hz
    replied
    Britoid the version check is disabled today. They might add it back due to massive code changes on shell.

    Leave a comment:


  • Britoid
    replied
    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.

    Leave a comment:


  • 144Hz
    replied
    Isedonde The reason for late merges is already explained. Many MRs from vanvugt are so experimental they need to be reverted and closed. You can’t merge that to master without good reason. So they need more testing. Ubuntu just moved to GNOME devel version. So any early merge would cause upstream testing stuff that Ubuntu haven’t exposed to their own testers. Ubuntu need to improve on this.

    It’s very likely we will get even later merges on shell. Also Canonical work. It’s high value but also disruptive. Extension version check might be reenabled due to this.

    Leave a comment:


  • Isedonde
    replied
    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!

    Leave a comment:


  • 144Hz
    replied
    pal666 Part of being enterprisy is that you understand the needs of customers. Endless expects to use picks on advanced surfaces. So they decided not to regress. Endless allocated a lot of resources to this feature.

    Endless went even further on the styling initiative. Downstreams now have a better way of organizing their modifications and themes.
    https://discourse.gnome.org/t/gtk-ad...-styles/1641/4

    That’s the enterprisy way of dealing with downstream modifications. Doing real work might prove to be a better solution than having forum spammer yelling “Theming API!!1”

    Leave a comment:

Working...
X