© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I believe the main problem right now is that neither Gnome or upstream people know what exactly the gradual slowdown problem is about, and/or where exactly in the stack it sits and/or how to consistently reproduced it. It's been like this for years.
Some more (probably) relevant bugs I'm following about this
Bug 667456 - gnome-shell becomes slow after a suspend/resume
https:/
ACTIVE Bug 642652 - Major memory leak on mutter when using gnome-shell
https:/
In my case, the Gnome Shell and/or mouse tracking slowdown visibly happens over time. Triggers involved seem to be working with large extended screens (I use 3440x1440 for extended desktop) and for apps, Google Chrome especially seems to somehow contribute to the phenomenon. I've also noticed a clear connection to stutter getting worse and then Gnome Shell soon crashing thereafter (crash trigger can for example be a right-click menu drawing).
But this by no means exhausts the problem vector list, which makes the issue so problematic.
I have not been able to find out with certainty whether anyone in the developer circle is even experiencing any UX degradation, which might be the top reason why it isn't getting fixed for years.
For example, if at the Gnome Shell performance dept nobody has a large monitor (3440p and up, incl. 4K) that they work with every day, I wouldn't be surprised if this degradation never shows.
I'd be happy to participate in crowdfunding a large monitor or maybe even fund it myself if someone just would say they are working on it and only needs more relevant hardware to diagnose and squash the issue.