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

[DebianLinuxero]

I'll be happy if just it not slow an Intel Atom.

[cybertraveler]

I was reading about GnomeShell, Mutter and Clutter and it has made me wonder why GnomeShell isn't using GTK+ 3.x instead of clutter. I'm pretty sure GTK+ can render to an OpenGL backend. GTK+ allows for the creation of custom widgets. GTK+ allows you to draw using Cairo calls.

What am I missing?

Also: I just found out that the predecessor of Mutter (the GnomeShell window manager) is Metacity and Metacity did use GTK+ (2.x).

Interesting side note: I just found out that Gnome 2.x used Enlightenment for it's window manager at one point (prior to using Metacity). With the current Enlightenment project working hard on being a great Wayland desktop, I wonder if the Gnome 3.x project would consider going back to relying on Enlightenment.

[Guest]

Gnome 3 is slow, bloated and broken by design. It's now confirmed. Thanks a lot for KDE devs!

[ebassi]

Even as someone who likes Gnome Shell its hard to deny that Clutter is a pos. Its always been inefficient and shitty, as demonstrated by the fact that it has such trouble running on old or underpowered hardware despite not really being all that complex in visual design or graphical effects.

First of all, and from the bottom of my heart: fuck off. You have zero clue about anything you just said. You should just delete your account.

Second: Clutter was developed to work on SoC from 2008, and on netbooks with crappy Atom CPUs and Intel integrated GPUs that barely had fragment shaders. It worked fine on those.

The problem is that if you start cramming features in, and you don't maintain the underlying toolkit, things don't get better.

[davidbepo]

The person who thought it was a good idea to put JS execution on the same thread should be tried for treason and violation of human rights.

and heresy

[ebassi]

I was reading about GnomeShell, Mutter and Clutter and it has made me wonder why GnomeShell isn't using GTK+ 3.x instead of clutter. I'm pretty sure GTK+ can render to an OpenGL backend. GTK+ allows for the creation of custom widgets. GTK+ allows you to draw using Cairo calls.

What am I missing?

You're missing that GNOME Shell, Mutter, and Clutter predate GTK+ 3.x, and its OpenGL support.

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.

Also: I just found out that the predecessor of Mutter (the GnomeShell window manager) is Metacity and Metacity did use GTK+ (2.x).

It didn't. It only used menus, and GDK in some places, but for the rest it was using Xlib directly everywhere.

Interesting side note: I just found out that Gnome 2.x used Enlightenment for it's window manager at one point (prior to using Metacity). With the current Enlightenment project working hard on being a great Wayland desktop, I wonder if the Gnome 3.x project would consider going back to relying on Enlightenment.

Hahahahah

No.

[Mthw]

I am sorry, but the title should be: GNOME 3 Might Be Too Resource Hungry To Ever Run Nicely On Anything

[Vash63]

You're missing that GNOME Shell, Mutter, and Clutter predate GTK+ 3.x, and its OpenGL support.

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.



It didn't. It only used menus, and GDK in some places, but for the rest it was using Xlib directly everywhere.



Hahahahah

No.

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

[cybertraveler]

You're missing that GNOME Shell, Mutter, and Clutter predate GTK+ 3.x, and its OpenGL support.

That explains it. Thanks.

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.

That doesn't follow. GnomeShell contains a compositor but it's misleading to say it is a compositor and therefore GTK+ is useless. GnomeShell would obviously need additional code to handle the compositing process and window management that GTK+ can't be used for. My point was it seems like GTK+ can already do many things which GnomeShell needs (drawing, animation, maintaining a stateful scene of GUI elements, various useful utility functions, text handling (indirectly)). So it seems plausible to me that GTK+ 3.x could be used by GnomeShell to replace many of the functions of Clutter (including drawing, animation, maintaining a stateful scene of GUI elements).

[ebassi]

That doesn't follow. GnomeShell contains a compositor but it's misleading to say it is a compositor

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

and therefore GTK+ is useless.

I didn't say "GTK is useless": I said "GTK is not a compositor toolkit". It simply does not work that way. It needs a display server (X11, Wayland, WIndows, Quartz) and cannot implement one; it assumes it owns all the top-level windows it creates; it consumes events from the window system. GTK+ is a client toolkit.

Of course it could be possible to add a backend to GTK that allows you to write a compositor and a window manager; it's hard work, and it's not in the scope of the GTK+ 4.x development.

GnomeShell would obviously need additional code to handle the compositing process and window management that GTK+ can't be used for.

That would be a major rewrite of GNOME Shell. Nobody is working on that either.

My point was it seems like GTK+ can already do many things which GnomeShell needs (drawing, animation, maintaining a stateful scene of GUI elements, various useful utility functions, text handling (indirectly)). So it seems plausible to me that GTK+ 3.x could be used by GnomeShell to replace many of the functions of Clutter (including drawing, animation, maintaining a stateful scene of GUI elements).

GTK+ 3.x won't ever be modified to be used inside the compositor; it's a stable, mostly feature frozen branch. Additionally, while it supports rendering OpenGL, it does not render with OpenGL, so it's pointless to compare it to the current Shell toolkit.

There are no plans for GTK+ 4.x to be able to write a compositor with it either.