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

[raster]

... what environment these days is lowresource and performant on such platforms? Enlightenment? ...

Just a data point... I just set up my odroid xu3 (I also have a rpi3 and didn't try it there though, but I should some time) to work again with GPU accel + Wyaland. I used an Ubuntu 18.04 spin with the Gnome-shell based Ubuntu desktop by default. I can't say for raw out of the box Gnome 3, but memory footprint of the system was:

Booted to text console: 80m
Running Enlightenment (current git master) with 1 terminal up: 156m
Running Ubuntu's Gnome shell with 1 terminal up: 701m

Raw data:

              total        used        free      shared  buff/cache   available
Mem:           1994          80        1763           6         150        1852
Swap:          1666           0        1666
              total        used        free      shared  buff/cache   available
Mem:           1994         156        1608           6         229        1775
Swap:          1666           0        1666
              total        used        free      shared  buff/cache   available
Mem:           1994         701         896          65         396        1171
Swap:          1666           0        1666

FYI both desktops have roughly similar features (file manager, launcher, virtual desktops, network controls, bluetooth controls, task switching controls, a fullscreen wallpaper etc. etc. - at least what is visible to the user).

[pal666]

A javascript runtime will always be a resource hog in whatever thread is running.

the issue here is not "resource hog in general", but "current cpu core resource hog", which is nicely solved by doing javascript in other thread. yes, javascript can lag, but your mouse cursor won't
i'm not trying to defend js here, i don't consider it real language

That is one of the technical reasons I won't touch Gnome 3 or Cinammon or any other javascript based desktop environment.

i wonder whether you disabled js in your browser, or posting via http-smtp gw

[pal666]

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

i'm confused, do you agree that unmaintained clutter became pos?

[pal666]

1. Only one thread can access the graphic subsystem; you cannot touch the GPU from multiple threads

not sure what you mean by touching, but surely you can render from multiple threads and even multiple processes

[pal666]

Seems there are no good, well supported toolkit choices for C these days

there are no good reasons for using c in the first place these days

[pal666]

Even a move to modern C++ would be huge but these days even bettter languages exist.

doubtful, since you listed worse languages

[sa666666]

I remember some guy that posted how GNOME was the Standard Linux Desktop.

Don't mention him, or he may appear again (unlikely, since his account has been blocked). But let's not tempt fate.

[pal666]

you'd have to free resources asynchronously because there's IPC involved

asynchronously does not mean garbage collector. freeing memory is fast (and does not have to happen on the main thread, btw)

The language has nothing to do with it, because those things happen in any language.

but those things could be orders of magnitude faster in better language. and they could be controlled in non-garbage-collecting language. some languages even allow you to avoid producing garbage in the first place

[dos1]

If you think the language matters, in this case, you're clearly even less knowledgeable than you think you are.

Of course the language itself has nothing to do with it. You could design a proper, performant and user extensible architecture around JavaScript, it's just a bit harder due to its characteristics, but not impossible (whether JavaScript is a sensible option for that is a completely different question ;P). However, Mutter failed at it big time - its current architecture would be bad even if everything was written in carefully handcrafted assembly.

Also, until recently, GNOME Shell used a garbage collected language without actually garbage collecting. Tells a lot about overall quality of this JS integration.

[ebassi]

not sure what you mean by touching, but surely you can render from multiple threads and even multiple processes

No, you can't. Only one thread, in OpenGL, can render at any given time. The whole OpenGL state machine is tied to Thread-Local storage. On Linux using multiple GL context tied to separate threads has also been historically fraught with driver issues.

The fact that you don't understand the difference between threads and processes also tells me you don't have the faintest clue what you're blabbering about.