5 ms·

Please remove this silly JS engine that's been implemented, poorly. It didn't attract mass developers, and it's ruined performance.

by axaxs 8y ago

pjmlp 8y ago
Fully agree, Ubuntu dropping Unity for GNOME made me an happy XFCE user. I still tried to use it for a couple of months, but the performance difference is quite noticeable.
- Jasper_ 8y ago
  I don't think the JS interface is the main performance bottleneck, honestly. I would start to look at Clutter and modernizing the GPU backend (e.g. using UBOs, using the depth buffer, batching texture binds, etc.) before thinking about killing the JS interpreter.
  - pjmlp 8y ago
    Might be, but it is does really lag behind what Unity was capable of, regarding performance.
  - floatboth 8y ago
    With Gtk 4 being based on a GPU accelerated scene graph thing, isn't it time to deprecate Clutter?
    - Jasper_ 8y ago
      This is a complex question. Using GTK+ in a window manager / compositor is tricky because GTK+ itself wants to talk to the window manager / compositor. So it's easy to end up in a deadlock. A DRM/libinput backend would have to be made for GDK and that's not an easy task, there are a lot of conceptual mismatches. I'm torn on whether it's the right way to go, basically.
  - axaxs 8y ago
    It may be or may not be anymore, but at one time not long ago it definitely was. When I cared enough to actually profile its performance, you could literally just move the mouse to the top corner to expose the dashboard, and back. Each time doing this, 4MB of memory gone for good. That particular bug has been fixed. JS engine memory leak. In fact, I invite anyone to look at the number of 'memory leak' commits in Gnome 3/Gnome Shell regarding its JS use.
VMG 8y ago
Wait what? There are hundreds of popular gnome extensions.
- pjmlp 8y ago
  With various degrees of CPU hogging.
  - VMG 8y ago
    which programming language has a similar popularity and would exhibit less CPU hogging?
    - pjmlp 8y ago
      If you want specific examples, C and C++ to start with, as the old GNOME plugins used to be written on, before they went JavaScript crazy with the UI. And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.
      - VMG 8y ago
        Neither C or C++ have the same developer reach or safety.
        pjmlp 8y ago
        Developer reach in what sense? Script kiddies writting GNOME extensiosn with 100% CPU use and memory leaks? As for safety, yes C++ and specially C are quite good at memory corruption bugs. Which I am quite aware, if you look at my comments history. Exactly because of that I took care to expressly mention "And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.". And while JavaScript might be safe in terms of memory corruption issues, there are enough WAT opportunities in the language.
m45t3r 8y ago
How about a PR? /s No, but really, saying things like "I hate the technical decisions made by your project, please change it" without really participating in the project is silly. It is like "why not Rust?" all over again.
erinaceousjones 8y ago
Disagree. "Dash to Panel", "Gnomesome" and "Topicons redux" extensions have got GNOME back to where I wanted it exactly. They're not extensions that add any appreciable CPU usage, because they're altering shell behaviour, rather than rendering stuff in a tight loop. My favourite tiling WM is awesome, and the majority of the interesting functionality for that is scripted in Lua, which is fast but more of a niche language. However, awesome doesn't support Wayland, and the awesome-clones for Wayland are all early-development and don't work very well for me. GNOME supports wayland, has session management, styles things consistently, has sensible defaults, and thanks to the JS engine and the extensions repo, can do exactly what I want it to do. (Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....)
- zozbot123 8y ago
  > (Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....) The point of the gigantic titlebars and widgets in GTK3 is to support touchscreens - you can "grab" the big titlebar on a touchscreen and move the window easily, which you wouldn't be able to do with traditional window decorations. Once you're constrained to a bigger titlebar, having widgets in there as well is just sensible. Windows 10 has chosen the alternative of just making the titlebar thicker without stuffing anything in there, which wastes more screen space! (I still think there should be a traditional, mouse-oriented layout for systems which don't support touch-- but guess what, that's quite hard. The default should be touch-friendly.)

Please remove this silly JS engine that's been implemented, poorly. It didn't attract mass developers, and it's ruined performance.

by axaxs 8y ago

Please remove this silly JS engine that's been implemented, poorly. It didn't attract mass developers, and it's ruined performance.

pjmlp 8y ago

Fully agree, Ubuntu dropping Unity for GNOME made me an happy XFCE user. I still tried to use it for a couple of months, but the performance difference is quite noticeable.

Jasper_ 8y ago
I don't think the JS interface is the main performance bottleneck, honestly. I would start to look at Clutter and modernizing the GPU backend (e.g. using UBOs, using the depth buffer, batching texture binds, etc.) before thinking about killing the JS interpreter.
- pjmlp 8y ago
  Might be, but it is does really lag behind what Unity was capable of, regarding performance.
- floatboth 8y ago
  With Gtk 4 being based on a GPU accelerated scene graph thing, isn't it time to deprecate Clutter?
  - Jasper_ 8y ago
    This is a complex question. Using GTK+ in a window manager / compositor is tricky because GTK+ itself wants to talk to the window manager / compositor. So it's easy to end up in a deadlock. A DRM/libinput backend would have to be made for GDK and that's not an easy task, there are a lot of conceptual mismatches. I'm torn on whether it's the right way to go, basically.
- axaxs 8y ago
  It may be or may not be anymore, but at one time not long ago it definitely was. When I cared enough to actually profile its performance, you could literally just move the mouse to the top corner to expose the dashboard, and back. Each time doing this, 4MB of memory gone for good. That particular bug has been fixed. JS engine memory leak. In fact, I invite anyone to look at the number of 'memory leak' commits in Gnome 3/Gnome Shell regarding its JS use.

VMG 8y ago

Wait what? There are hundreds of popular gnome extensions.

pjmlp 8y ago
With various degrees of CPU hogging.
- VMG 8y ago
  which programming language has a similar popularity and would exhibit less CPU hogging?
  - pjmlp 8y ago
    If you want specific examples, C and C++ to start with, as the old GNOME plugins used to be written on, before they went JavaScript crazy with the UI. And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.
    - VMG 8y ago
      Neither C or C++ have the same developer reach or safety.
      - pjmlp 8y ago
        Developer reach in what sense? Script kiddies writting GNOME extensiosn with 100% CPU use and memory leaks? As for safety, yes C++ and specially C are quite good at memory corruption bugs. Which I am quite aware, if you look at my comments history. Exactly because of that I took care to expressly mention "And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.". And while JavaScript might be safe in terms of memory corruption issues, there are enough WAT opportunities in the language.

m45t3r 8y ago

How about a PR? /s No, but really, saying things like "I hate the technical decisions made by your project, please change it" without really participating in the project is silly. It is like "why not Rust?" all over again.

erinaceousjones 8y ago

Disagree. "Dash to Panel", "Gnomesome" and "Topicons redux" extensions have got GNOME back to where I wanted it exactly. They're not extensions that add any appreciable CPU usage, because they're altering shell behaviour, rather than rendering stuff in a tight loop. My favourite tiling WM is awesome, and the majority of the interesting functionality for that is scripted in Lua, which is fast but more of a niche language. However, awesome doesn't support Wayland, and the awesome-clones for Wayland are all early-development and don't work very well for me. GNOME supports wayland, has session management, styles things consistently, has sensible defaults, and thanks to the JS engine and the extensions repo, can do exactly what I want it to do. (Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....)

zozbot123 8y ago
> (Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....) The point of the gigantic titlebars and widgets in GTK3 is to support touchscreens - you can "grab" the big titlebar on a touchscreen and move the window easily, which you wouldn't be able to do with traditional window decorations. Once you're constrained to a bigger titlebar, having widgets in there as well is just sensible. Windows 10 has chosen the alternative of just making the titlebar thicker without stuffing anything in there, which wastes more screen space! (I still think there should be a traditional, mouse-oriented layout for systems which don't support touch-- but guess what, that's quite hard. The default should be touch-friendly.)