GNOME 3 Might Be Too Resource Hungry To Ever Run Nicely On The Raspberry Pi

[ebassi]

Any comment on the chances of the compositor thread being separated from js extensions and anything else?

There's a lot to unpack, here.

1. Only one thread can access the graphic subsystem; you cannot touch the GPU from multiple threads
2. There is no such thing as a "JS extension": all the code written in JavaScript is running in the same context (that's what allows writing extensions in the first place), and all the JavaScript code ends up rendering something — either directly or indirectly
3a. You cannot move things in separate threads in the hope the garbage collection won't stall the compositing thread because you cannot free a resource created inside a thread from another thread; the Shell has multiple windowing system resources, which means that they have to be freed in the same thread that created them, which happens to be the compositing thread
3b. If you think this would go away with a different language, you're sorely mistaken
4. Anything that can be moved to a separate thread — input polling, I/O — is either in the process of being moved there, or already moved; some things, like uploading texture data to the GPU, can cause stalls, but they need to happen on the main thread because OpenGL works that way

[starshipeleven]

There's a lot to unpack, here.

1. Only one thread can access the graphic subsystem; you cannot touch the GPU from multiple threads
2. There is no such thing as a "JS extension": all the code written in JavaScript is running in the same context (that's what allows writing extensions in the first place), and all the JavaScript code ends up rendering something — either directly or indirectly
3a. You cannot move things in separate threads in the hope the garbage collection won't stall the compositing thread because you cannot free a resource created inside a thread from another thread; the Shell has multiple windowing system resources, which means that they have to be freed in the same thread that created them, which happens to be the compositing thread
3b. If you think this would go away with a different language, you're sorely mistaken
4. Anything that can be moved to a separate thread — input polling, I/O — is either in the process of being moved there, or already moved; some things, like uploading texture data to the GPU, can cause stalls, but they need to happen on the main thread because OpenGL works that way

Ok, is it fair to speculate that with Vulkan you would be able to do better because it allows more multithreading?

[cen1]

I call bullshit on that.. at least extensions could be moved to a seperate JS engine and exchage via IPC.

[gamerk2]

Ok, is it fair to speculate that with Vulkan you would be able to do better because it allows more multithreading?

At the very least, Vulkan allows multiple threads to talk to the GPU/graphic subsystem.

[dos1]

You're also missing that GTK+ is not a compositor toolkit; you can't use widgets inside your compositors, and you can only use override-redirect windows, like menus. Additionally, GTK+ does not have a framebuffer backend, so you cannot write a Wayland compositor with it.

Just switch to Qt and finally make a decent DE out of it.

Oh, actually, you don't have to - Plasma already exists :P

(yes, I'm aware Qt in C is a no go. Sadly, GTK+ went downhill in recent versions, and EFL is... well, EFL. Seems there are no good, well supported toolkit choices for C these days )

[darkbasic]

It would be very interesting to know how KDE's Plasma compares to Gnome 3 on the Raspberry Pi.

[johanb]

GNOME Shell is a compositor. You cannot separate the compositor from the window manager from the display server.

https://en.wikipedia.org/wiki/GNOME_Shell

"GNOME Shell is written in C and JavaScript as a plugin for Mutter."

https://en.wikipedia.org/wiki/Mutter_(software)
"Mutter is a window manager initially designed and implemented for the X Window System, and recently has evolved to be a Wayland compositor"

[wizard69]

While i never understood the stupidity of Javascript being used in a key aspect of a GUI, i must say Gnome behaves better than Windows 10. That isnt saying much though.

As for Raspberrry PI who would rationally run resource heavy Windowing systems on the platform? If you dont understand your hardwares capabilities whom is to blame.

this brings up the question; what environment these days is lowresource and performant on such platforms? Enlightenment? KDE ( never liked it)? FVWM (does it still exist)? In any event Raspberry PI has the volume to justify something tailored to its neeeds. Complaing about Gnome on the platform just seeems misplaced in my mind. Now complaints about its behavior on modern hardware designed to run modern operating systems is another thing and highly justified.

[pracedru]

This is going to be an issue for the Librem5 as well :|

[Candy]

And if it worked fine on those shits, then what happened now and can't even run flawlessly on high-end machines?

It doesn't work fine on those machines. I do own one of these machines and Gnome3 is slow as suck (Fedora 28 with nearly everything removed that is not needed). Same applies on the system that my sister runs (i3, HDD, 8gb Ram). I installed Fedora 28 (with all services removed, tracker disabled and all that crap package management running in the bg). Gnome3 stutters, mouse movement stutters. It works! But it's not compareable if I run Xfce4 on the same system (which works fluent).

Gtk3 is also sluggish slow. I noticed a huge performance loss (in rendering and drawing of widgets). e.g. A lot of popup menus and windows show a black rectangle for around 1 second before anything is drawn on them. Been having this for quite some Fedora releases. This is totally noticable e.g. in xfce4-whiskermenu-plugin (Gtk3) and some other applications. Gtk3 Filechooser takes up to 3 seconds to actually pop up here. Even on the i3 system of my sister.