GNOME 40's Shell Theme Code Is Rather Expensive But Optimization Pursued

[gedgon]

There is something wrong on your side. I can not reproduce this performance regression. But I am also not using 70s tech display servers so maybe its that.

There is nothing wrong on my side https://gitlab.gnome.org/GNOME/gnome.../-/issues/3760
!1441 doesn't work on Wayland yet.

[Alexmitter]

I don't disagree that running a full blown Chromium instance just for a simple chat program is overkill and wasteful. But you have to look at it from the other side as well. Developers aren't given much of a choice when it comes to multi-platform development. Deployment is hard, especially on Linux. Electron seem to eliminate a lot of the burden you get with something like C/C++. Maybe you had a library like Qt in mind as an alternative, cross-platform and fast. That's true, but it's also very tedious to deploy on Linux and even MacOS. No, you cannot rely on system versions of Qt because they may be older or newer than what you compiled your binaries with, and even if you program runs, the version that is in the user's machine may contain a bug that you didn't anticipate, causing unexpected regressions/crashes. You have to ship your own Qt-library with your app, and you have to ship all libraries that Qt itself is dependent on that you cannot reliably expect to be on your users' target systems. That may include trivial things like gstreamer1.0 and its plugins. This may of course cause you licensing issues if you're not careful. You also have to compile on an older or as new of a system as your users' target system, or else glibc is gonna scream! And don't get me started with MacOS.

Qt also has an inferior styling system to HTML5/CSS3, the Qt developers even planned to deprecate their StyleSheet-system which is the only thing close to CSS, because they realized that it's not powerful enough and causes problems for some developers. Also, your code ends up being an unmaintainable mess. Yes, you can paint stuff yourself, and QPainter is insanely powerful and fast (albeit not GPU accelerated, so forget fancy animations), but that's way more difficult to deal with than HTML5/CSS3. Yes, you can use QPalette to choose from a limited set of identifiable and configurable colors/gradients/images, but their number is limited, and there is no way for you to do things like rounding corners of buttons, for that you'll need QPainter or StyleSheets.



So please, understand GUI app developers don't have it easy, especially on Linux. Choices are limited, even in 2021. It's not about being lazy, it's about not having to deal with 10x the development effort for a problem that, let's be real, has "solved itself". It's a sad state of affairs, and the only way to solve it is to offer stable, sustainable and serious frameworks for cross-platform devs that are based on fast languages. If we don't have this, you seriously cannot blame HTML/CSS/JS devs for choosing Electron.

Then make a website if that is all you(speaking to those GUI app developers) can, there is no need to ship a full blown browser with your website.

The situation with (semi-)native toolkits is not perfect, but its so much better then wasting gigabytes of ram for that worst application runtime enviroment known to man.

[Alexmitter]

That's strange. 40 is significantly slower than 3.38. Here are some numbers. Overview animation, 20 windows, with !1441

mutter 3.38.4+9+g607803c4b / gnome-shell 3.38.4
*** X11 screen performance over 1.0s: 60.04 FPS, average: 8.0ms, peak: 15.1ms
*** X11 screen performance over 1.0s: 60.02 FPS, average: 12.9ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 59.99 FPS, average: 12.8ms, peak: 14.2ms
*** X11 screen performance over 1.0s: 59.97 FPS, average: 12.8ms, peak: 13.9ms
*** X11 screen performance over 1.0s: 60.00 FPS, average: 12.8ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 60.02 FPS, average: 12.7ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 57.73 FPS, average: 12.5ms, peak: 18.0ms
*** X11 screen performance over 1.0s: 60.26 FPS, average: 13.0ms, peak: 14.6ms
*** X11 screen performance over 1.0s: 57.89 FPS, average: 13.0ms, peak: 18.4ms

mutter 40.0+51+gcf8efb582 / gnome-shell 40.0+37+g1f0ef7fb4
*** X11 screen frame timings over 1,0s: 36,14 FPS, average: 19,6ms, peak: 23,9ms
*** X11 screen frame timings over 1,0s: 35,87 FPS, average: 17,8ms, peak: 24,1ms
*** X11 screen frame timings over 1,0s: 35,48 FPS, average: 18,1ms, peak: 25,5ms
*** X11 screen frame timings over 1,0s: 35,46 FPS, average: 17,7ms, peak: 26,0ms
*** X11 screen frame timings over 1,0s: 34,39 FPS, average: 20,0ms, peak: 27,2ms
*** X11 screen frame timings over 1,0s: 32,93 FPS, average: 20,4ms, peak: 28,3ms
*** X11 screen frame timings over 1,0s: 32,56 FPS, average: 20,9ms, peak: 28,7ms
*** X11 screen frame timings over 1,0s: 33,33 FPS, average: 19,1ms, peak: 28,1ms

There is something wrong on your side. I can not reproduce this performance regression. But I am also not using 70s tech display servers so maybe its that.

[board]

... A messenger that used 40 MB memory was considered bloated a few years ago, now we got messengers that use gigabytes of memory with basically the same or even less functionality thanks to hip new web technologies.

I mean JavaScript in the desktop? What an amazing idea...

I don't disagree that running a full blown Chromium instance just for a simple chat program is overkill and wasteful. But you have to look at it from the other side as well. Developers aren't given much of a choice when it comes to multi-platform development. Deployment is hard, especially on Linux. Electron seem to eliminate a lot of the burden you get with something like C/C++. Maybe you had a library like Qt in mind as an alternative, cross-platform and fast. That's true, but it's also very tedious to deploy on Linux and even MacOS. No, you cannot rely on system versions of Qt because they may be older or newer than what you compiled your binaries with, and even if you program runs, the version that is in the user's machine may contain a bug that you didn't anticipate, causing unexpected regressions/crashes. You have to ship your own Qt-library with your app, and you have to ship all libraries that Qt itself is dependent on that you cannot reliably expect to be on your users' target systems. That may include trivial things like gstreamer1.0 and its plugins. This may of course cause you licensing issues if you're not careful. You also have to compile on an older or as new of a system as your users' target system, or else glibc is gonna scream! And don't get me started with MacOS.

Qt also has an inferior styling system to HTML5/CSS3, the Qt developers even planned to deprecate their StyleSheet-system which is the only thing close to CSS, because they realized that it's not powerful enough and causes problems for some developers. Also, your code ends up being an unmaintainable mess. Yes, you can paint stuff yourself, and QPainter is insanely powerful and fast (albeit not GPU accelerated, so forget fancy animations), but that's way more difficult to deal with than HTML5/CSS3. Yes, you can use QPalette to choose from a limited set of identifiable and configurable colors/gradients/images, but their number is limited, and there is no way for you to do things like rounding corners of buttons, for that you'll need QPainter or StyleSheets.



So please, understand that GUI app developers don't have it easy, especially on Linux. Choices are limited, even in 2021. It's not about being lazy, it's about not having to deal with 10x the development effort for a problem that, let's be real, has "solved itself". It's a sad state of affairs, and the only way to solve it is to offer stable, sustainable and serious frameworks for cross-platform devs that are based on fast languages. If all we have is the aforementioned (and GTK which is not even close feature-wise), can you seriously blame devs for using Electron?

[Alexmitter]

Compiz was always smoother and a better optimized compositor. Also Unity was a better DE than gnomeshell.

Unity ran like shit on devices where even a old gnome shell ran acceptable. We still have some who are stubborn to update from their Ubuntu 16.04, its so damn bad.

[kpedersen]

And here I thought you were going to comment that DE's shouldn't need GPU acceleration in the first place

To be honest, that was pretty much exactly what I was hinting at. Especially if Gnome 3 wants to at least pretend it is a great experience on mobile platforms (as a justification for trashing and regressing the desktop experience).

[You-]

After every major update it is always worth revisiting performance.

The new updated added alot more rounded corners and that generally does have a performance impact.

First step was getting the work merged when it was good enough - any further delays and it wouldnt have been. Now that it has, any performance regressions can be targetted. that is proper development so i dont get why the people are moaning.

As for who the gnome developer is, both are:

Daniel Van Vugt is a Gnome developer working for Canonical
Georges Basile Stavracas Neto is a Gnome developer working for another company now foundation that I have forgotten the name of.

People on here just love being ungrateful.

[gedgon]

Considering that Shell40 is noticeable faster/more fluent on all of my systems compared to 3.38, I wonder how this is possible.

That's strange. 40 is significantly slower than 3.38. Here are some numbers. Overview animation, 20 windows, with !1441

mutter 3.38.4+9+g607803c4b / gnome-shell 3.38.4
*** X11 screen performance over 1.0s: 60.04 FPS, average: 8.0ms, peak: 15.1ms
*** X11 screen performance over 1.0s: 60.02 FPS, average: 12.9ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 59.99 FPS, average: 12.8ms, peak: 14.2ms
*** X11 screen performance over 1.0s: 59.97 FPS, average: 12.8ms, peak: 13.9ms
*** X11 screen performance over 1.0s: 60.00 FPS, average: 12.8ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 60.02 FPS, average: 12.7ms, peak: 13.6ms
*** X11 screen performance over 1.0s: 57.73 FPS, average: 12.5ms, peak: 18.0ms
*** X11 screen performance over 1.0s: 60.26 FPS, average: 13.0ms, peak: 14.6ms
*** X11 screen performance over 1.0s: 57.89 FPS, average: 13.0ms, peak: 18.4ms

mutter 40.0+51+gcf8efb582 / gnome-shell 40.0+37+g1f0ef7fb4
*** X11 screen frame timings over 1,0s: 36,14 FPS, average: 19,6ms, peak: 23,9ms
*** X11 screen frame timings over 1,0s: 35,87 FPS, average: 17,8ms, peak: 24,1ms
*** X11 screen frame timings over 1,0s: 35,48 FPS, average: 18,1ms, peak: 25,5ms
*** X11 screen frame timings over 1,0s: 35,46 FPS, average: 17,7ms, peak: 26,0ms
*** X11 screen frame timings over 1,0s: 34,39 FPS, average: 20,0ms, peak: 27,2ms
*** X11 screen frame timings over 1,0s: 32,93 FPS, average: 20,4ms, peak: 28,3ms
*** X11 screen frame timings over 1,0s: 32,56 FPS, average: 20,9ms, peak: 28,7ms
*** X11 screen frame timings over 1,0s: 33,33 FPS, average: 19,1ms, peak: 28,1ms

[...] write a new DE from scratch. It is not worth fixing.

Yes, you do that!

[jo-erlend]

Just dump, abandon gnome shell and write a new DE from scratch. It is not worth fixing.

Gnome Shell works very well and it allows for constructive divergence in the form of OS differentiation without forks and community splits. I think it's great.

[jo-erlend]

In my years of experience, Compiz was nice, but also buggy. I do agree that Unity was better, though.

There are two different products named Compiz. It's the 0.8 version and the 0.9-based version. 0.9 is a reimplementation in C++. It took a while to get there, but in my opinion, it did.

Unity _is_ good. Why the past tense? It will never support Wayland and will never be suitable for a containerized desktop system, but I'm not sure that's a bad thing. Unity can remain a shell for traditional non-container desktops. It'll sort of be like a Windows XP for the Linux world and that's not a bad thing.