@vanvugt, the video stutter is because of the indicator-multiload or this is because the server side of the indicator-multiload is running inside the compositor thread? It’s true that the indicator-multiload is heavy and is also true the Ubuntu implementation of the indicator is really questionable right now as this is happening for all images that AppIndicator receive in the gjs side (https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/005fe8b8280c2bdb65fa5927de2e2ed60def0480/appIndicator.js#L477-L490). But a video stutter should not happens if the indicator-multiload will be running outside the compositor.
I know I am repetitive, but it is repetitive to see how the 3rd parties apps are blamed for the bad architecture of the shell. Isn’t it a good idea to finish fixing the shell architecture at once? i.e.: I think all GUI process should be moved outside the compositor thread. I’m pretty sure at less a video stutter should not occurs in that way. Thanks for sharing all the shell progress and your own work on this.
Edit: In the title of bug 1879604 it said:
On a 4k monitor, firefox playing 4k youtube video stutters… whereas in Unity it is smooth.
So, it’s not just the problem of bug 784055 , something different to Unity is happening to the issue reporter in gnome-shell. That “something” is the point of my comment.
Edit2: To reproduce the reporter issue, just create an extension that execute an spawn command line in sync mode every 1 seconds (for example). Then open a video in firefox and you will see the video stutter. The spawn_command_line_sync it is slow enough to slowdown the compositor thread and it cause a stuttering. Any delay in the compositor thread tends to create the same effect. The indicator-multiload is complex, so it enough the delay that it introduced in the compositor for the bad effect of stuttering to occur. Of course, executing spawn_command_line_sync in a gjs application, outside the compositor thread does not generate the problem at all.