4 ms·
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,
by 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 agoMight be, but it is does really lag behind what Unity was capable of, regarding performance.
- floatboth 8y agoWith Gtk 4 being based on a GPU accelerated scene graph thing, isn't it time to deprecate Clutter?
- Jasper_ 8y agoThis 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 agoIt 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.