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

[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.

[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).

[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.

[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]

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.

[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.

[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.

[board]

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.

A lot of web-based GUI apps do have browser-version as well. But having a stand-alone application outside of your browser can enable developers to use more powerful capabilities that would otherwise be sandboxed off from the app (for good reasons), like filesystem access, minimize to tray, stand-alone window without the tab-bar, bookmark field, etc. saving screen real-estate, access to other APIs that would have posed a security and privacy threat had they been accessible by normal websites.

Again, I do not disagree with you that it's wasteful, it's just that Electron seem to be the best alternative for developers. It's not good for the end-user, sure, but that doesn't justify the high development cost of the alternative frameworks we have today.

[ssokolow]

I had to uninstall file-roller and deal with archives the commandline way for several weeks. Reason being that opening any archive with file-roller will (almost always) send the gnome 3.38 desktop in a deathspin, flooding the log with javascript errors. The systems so bogged down I cant even switch to a VT.
Drag and dropping files sometimes kills all nautilus instances, sometimes the target (gnome-terminal for me).

That's nothing new. IIRC, file-roller has had a bug where drag-and-drop could hang it with an exclusive pointer grab (requiring Ctrl+Alt+F2 and a killall file-roller) since at least Lubuntu 14.04 when I noticed it. I can't remember whether it was fixed by 16.04, but they don't seem to test their DnD very well.

[mppix]

nah, people just want to be angry about something. it doesn't matter really. it's just your everyday internet...

I thought so but this thread made me want to check that I'm still grounded in reality.