GNOME Shell + Mutter Begin Landing Graphene Integration

[phoronix]

Phoronix: GNOME Shell + Mutter Begin Landing Graphene Integration

In the newest development code of GNOME Shell and Mutter for GNOME 3.36, Graphene integration has begun to replace some elements of Clutter...

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Shell-Mutter-Graphene

[davidbepo]

given that mutter means metacity clutter after the work is completed it should be renamed to maphene

[Britoid]

Curious whether this will have any noticable impact on performance of the shell.

[aufkrawall]

I suspect they would need to implement more fundamental changes to the whole shell/compositor design, especially on Wayland. Looks like dumb design flaws of threads stalling each other etc.

[Britoid]

Performance work by Georges landed as well.
https://gitlab.gnome.org/GNOME/mutte...e_requests/402

Georges just started working on the new login/lock screen too, he's literally a god.

[aufkrawall]

Is anyone working on a true hardware cursor, presentation feedback and proper vsync for xwayland windowed?
All those things are missing in Gnome 3.34 Wayland, while they are there with Sway.
There can be tons of other optimizations: Without such key issues solved, it will always be bad.

[V1tol]

I wonder if these changes will be more noticeable than removing JavaScript

[Britoid]

I wonder if these changes will be more noticeable than removing JavaScript

The javascript tells the native code (written in C) what to do.

So most performance problems aren't caused by the Javascript.

[sarmad]

The javascript tells the native code (written in C) what to do.

So most performance problems aren't caused by the Javascript.

I'm not familiar with Gnome Shell code, someone familiar with it can confirm. But my guess is that the rendering is happening in native code, but the animation loop itself and updating the props of moving objects is all happening in Javascript.

[V1tol]

The javascript tells the native code (written in C) what to do.

So most performance problems aren't caused by the Javascript.

And now think how much overhead this implementation has? Especially when lots of addons are written in Javascript, which are updating 60+ frames per second and every one should tell native code what to do. Run JS, serialize a message to native code, then native code parses that message and understands what to do. Maybe it is not super CPU consuming but it definitely has a flaw - long pipeline which results to a noticeable delays. Me as NodeJS developer know that sometimes libraries with native bindings appear to be slower than plain JS libraries (true story - XML parser in one of my projects) - because of relatively heavy bridging between native and JS code. And knowing that Gnome uses JS as DE driver scares me to hell.