So making it as fast and light as Xfce, LXQt, MATE & Plasma? That should be interesting. I may not use Gnome shell, but this would definitely make the desktop environment arena much more interesting. Good luck!
2 Likes
Will these improvements help people who use Gnome Flashback?
Its interesting to hear what fixes have been going into Gnome by canonical for the upcoming distro releases.
Its nice to finally have some numbers for the percentage of the code base in C vs JS though its hard to make any kind of comparison without including size as a metric as well.
I wanted to say those numbers can’t be right because if those numbers are correct, that would mean most of the codes documentation is largely undocumented at this point. The most documented parts of Gnome are the API and JS bindings, there’s almost no documentation except for the source code on the C internals and much of the documentation available from the gnome site is stale (hasn’t been updated in at least 10 minor releases).
There are a lot of people that would like to contribute, but can’t because the documentation is in such a bad place, and there are at least some that won’t switch to gnome without having a clear picture of how it works.
Can you comment on any tips or tricks the canonical team uses internally to get up to speed when working with Gnome given the current state of Gnome’s documentation?
2 Likes
Yes, everything applies to Flashback.
No. GNOME Flashback does not use mutter or gnome-shell. GNOME Classic does use GNOME Shell and mutter. (GNOME Classic is currently available in the gnome-shell-extensions package but maybe eventually it will get moved to a better named package).
2 Likes
First, thank you so much for your work on all of this. I’ve been following all of these issues for a long time and I’m still following more in hopes that I can one day use my Quadro M1200 laptop with my two external monitors. Without you fighting the good fight, I would have no hope of ever making use of my hardware.
Unfortunately, I’ve killed so much time just trying to achieve a stable system using just one monitor with my laptop screen turned off, and every time I make it work I’m terrified to do updates or reboot my system because it’s hard to keep it working.
On the latest updates with the 440 driver I still can’t boot up or login with my external monitor plugged in. Using two screens makes everything super laggy and slow. I had to set “use_root_rights=yes” in Xwrapper.config just to get it to detect my monitors and using the proprietary driver I still can’t get Wayland to even show up as an option logging in with GDM. It shows up with lightdm but that breaks other things. My brother has the same laptop but not the same issues, despite comparing every variable I know of.
I’m not sure all the issues are even tracked but there are so many variables I’m not even sure where to report anything or what exactly to report.
1 Like
Threading is something that I would recommend if starting a new project from scratch. When done well it will definitely improve performance. It’s only risky to introduce to a large project that already relies on being single threaded. That means it has very little awareness/safety of concurrent memory accesses etc.
Also worth noting that threads do not “isolate problems” or increase security at all. Because threads share memory with each other. Zero isolation or security. If you want those things then you need to put each component in a different process, like Chrome does with browser tabs.
7 Likes
I’m not a developer but just an ordinary Ubuntu desktop user but even to someone like me, this article made a very interesting read. Just getting a look into how the developers tackle certain usability problems and improve the performance of an existing system is quite an eye opener. Thank you for all your good work and creating something which benefits a whole ecosystem of users 
3 Likes
Also worth noting that threads do not “isolate problems”…
Well yes… The original idea is create a different process for all the GUI (the shell part), not just a different thread. But apparently some GNOME developers thinks also that have a different thread will be probably enough: https://www.youtube.com/watch?v=QgZRU9eQqKc&t=484s
It’s only risky to introduce to a large project that already relies on being single threaded…
Yes probably, but programming is take risk always or not? No do anything is take more risk in my opinion. In GNOME you are in fact the prove of that theory because you are doing things also when not all people are convinced about what you are doing.
Thanks for answer me. Now I understand your point, is just that i prefer the risk over the alternative of do nothing and have a single thread forever…
1 Like
The documentation I personally use the most is the Clutter documentation. Clutter is the core of Gnome Shell and Mutter and is primarily maintained inside the Mutter project. So it’s the main thing to learn.
The above web site isn’t completely up to date with the source code that lives in Mutter, but is mostly still accurate. The public API and documentation there change very little.
2 Likes
- Make sure you have a Launchpad account.
- Open a Terminal window and run:
ubuntu-bug gnome-shell
That should help you to create a detailed bug report which we can then analyse and answer.
5 Likes
Dumb question : will any of the fixes done here at a drivers / gtk level improve Unity?
1 Like
Unity does not use mutter or gnome shell, so improvements to these will have no effect.
2 Likes
Thank you so much for this. I understood 0.4% of it but it is super interesting and please keep posting stuff like this. It is very enlightening.
3 Likes
I’m using ubuntu on wayland for a while (Unity and Gnome since Unity abandon). But with ubuntu 19.10 upgrade, Gnome was so slow and laggy that I had thought to downgrade or a new laptop. I switched back to Xorg and now everything is as smoth as usual.
I have an intel card, don’t know if it can help.
1 Like
Nice read. Nice work. I will definitely check out 19.10 soon to see it for myself.
1 Like
Sorry for the delay; I just got back from vacation.
I would like to investigate your performance issue in more detail, but not here… Please run this command on the affected machine to open a new bug:
ubuntu-bug gnome-shell
1 Like
Finally I’ve had also this problem with xorg. It seems that it’s related to a kernel problem:
https://askubuntu.com/questions/1185491/ubuntu-19-10-freezes-and-lags-reguarly
It’s a shame that your work is masked by other problem. Thanks for the nice work (and article).
1 Like
@vanvugt I would like to ask for some clarification about your answer to my comment in Gnome Gitlab about frequency scaling. Since it was becoming a bit OT there and it’s a question of a more general nature about the way to tackle the animation that is most obviously lacking in Gnome Shell (the overview animation, of course), I opted to ask you here. What surprised me in your answer is that you say that good frequency scaling has to been seen only as a workaround here because resolving the underlying issues will make it less relevant or pressing. Now, as I understand it, this animation is processing intensive and, by its very nature, demands a processing burst when the CPU/GPU less expects it, so no “moving average” heuristic will do it and you need either to lock frequency too high and burn your battery out or scale frequency too fast. How can you work around this issue? Do you mean to implement the altogether different approach of snapshotting as described here?
1 Like
I know with performance issues distinguishing between a fix and a workaround can seem arbitrary. In this particular case I have a plan which seems to work in preliminary testing. And it works more reliably, and faster/smoother, without forcing frequency scaling harder. The animations are not as you say “processing intensive and, by its very nature, demands a processing burst”. They’re just being slowed down by a bug for which higher frequencies are a workaround, but it’s also possible to fix. That set of fixes is my current focus this month.
I agree more responsive frequency scaling would improve the user experience, as I have experienced myself when I first proposed it. Although that got reverted because it exposed bugs in the Wayland backend so will need to be reattempted in future. And I made another different attempt at scaling over the new year. So I haven’t given up on scaling, only deprioritised it for the moment.
5 Likes