GNOME Shell + Mutter Begin Landing Graphene Integration

[MrCooper]

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.

What exactly do you mean by "proper vsync for xwayland windowed"? That's ultimately an Xwayland issue and needs to be solved there, nothing the Wayland compositor can do about it (other than maybe not reparenting windows for the decorations, so they can actually hit the "fullscreen" path in Xwayland).

"Mutter" also means "nut" in Swedish. Make of that what you will

(nut as in "nuts and bolts", not the other kind..)

It has the same meaning in German, as well as "mother". The mother of compositors.

[stingray454]

Mutter is a brilliant name. Mother of all compositors

"Mutter" also means "nut" in Swedish. Make of that what you will

(nut as in "nuts and bolts", not the other kind..)

[starshipeleven]

V1tol No need for me to do profiling. The developers already did. And no findings support your guessing.

[citation needed]

[starshipeleven]

Mutter is a brilliant name. Mother of all compositors

Your fanboyism is disgusting

[V1tol]

V1tol Got any profiling to back up the talk?

I don't have neither knowledge nor time to profile GNOME. If you do, you can do profiling by yourself, show everyone that JS does not influence badly on overall performance and I will be the first person who will say "okay I was wrong". And what profiling will indicate in this case, since we should compare GNOME with JS and GNOME without JS to define overhead of Javascript?

But I do have user experience of GNOME on 12" Atom-based tablet. And even Clear Linux with latest GNOME is ridiculously slow in comparison of not-so-mega-optimized Ubuntu-based KDE Neon. And I do want to use GNOME on this tablet because it is really suitable for touchscreen but it eats CPU and consumes 1GB out of available 4GB RAM.

[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.

[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.

[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.

[V1tol]

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

[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.