Re:GNOME Shell and Mutter
by Jasper_ on Friday February 01, 2019 @01:19AM
(#19052045)
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.
[ Parent
| on HN ]
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.
Might be, but it is does really lag behind what Unity was capable of, regarding performance.
With Gtk 4 being based on a GPU accelerated scene graph thing, isn't it time to deprecate Clutter?
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.