Comment 158 for bug 1690719

Mike, Gtk4 is an amassing improve of the Gtk toolkit, if we compare it to any previously versions. After the introduction of Gtk4, will also be interesting re-thinking the real advantage that right now provide St and Clutter, compared with directly implement the shell with Gtk (Gtk4). Previously to the Gtk4, the option was Clutter as it have 3D acceleration support by default (Gtk3 not) and because it have a reduced set of API which allows to have a lighter shell than with Gtk. The last idea will continues be in that way.

Anyway, in theory at less, the release of Gtk4 will not affect the shell at all. It need to be a conscience decision, if you want a migration from st-clutter technology to the Gtk4 toolkit. But the decision of migrate the shell from st-clutter to Gtk4 has not been taken at this moment, so we can not ensure that this will happens at all and then we can not wait for that decision or have a plan as a dependency of that.

On the other hand, split the Shell-GUI task and the WM things in separately process is a totally independent thing of what toolkit you use and then will be the same job if it's for Clutter or if it's for Gtk. So, i really don't see the point of be waiting for a new version of Gtk if what really is needed is an architecture decision.

Certainly an architecture change at that level involve rethinking a lot of things and previously create a shared API of Mutter to be used from outside (the shell process) and that API is not yet there. So, I think we can conclude that there are not any intention to go in the direction of split the process yet.

That then means to me, that all us that are waiting for a multi-thread shell in this issue, will continues be waiting. But that not means to me that i will change and stop wanting the solution that a lot of us are waiting for years.

I think we all want to run a shell process with a very higher demand of CPU without blocking the compositor in the most critical point, when the WM is drawing/compositing the windows. I know that i can do that with the right architecture, but I can not do that currently with 16 cores and 32 process, so to me, i have the hardware for it, but I'm waiting for the software yet. None of the solution i see will really help to solve that user-case. The current solutions are just in the direction of minimized the impact, something that is also good, but non of this are the solution I'm waiting for. The current solutions are not even close to that.