Comment 19 for bug 784055

The indicator-multiload is heavy and the current Ubuntu implementation of the AppIndicator have a temporary questionable workaround that transform an all images from argb to rgba inside the compositor from gjs:

https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/005fe8b8280c2bdb65fa5927de2e2ed60def0480/appIndicator.js#L477-L490

But although the indicator-multiload is heavy, the video stutter should not happening just because of that. This is why i think there are also a shell problem behind that and this problem is really not new. Please see:

https://bugzilla.gnome.org/show_bug.cgi?id=687362

A lot of thing can block the compositor thread, but what is worse is that non one can know the next thing that will block it. Specially because it can come from a shell extension, as this is the case. So, I think that find a solution only to the case of the indicator-multiload, will not help in general to find a solution to the underlying problem.

One different way to reproduce the video stutter, can be create an extension that execute an spawn command line in a sync mode every 1 seconds (for example). Then if we open a video in firefox we can see the video stutter problem. In my opinion as same as the spawn_command_line_sync, the indicator-multiload is stopping the compositor thread and this is the real cause of the video stuttering. More over, any execution that delay the compositor thread tends to create the same effect. This can be, for example, the installation of a package that make a full apps menu update.

The indicator-multiload is complex, so it enough the delay that it will 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. Also as the indicator-multiload is not the only possible code that can delay the execution of the compositor thread, finding a solution with base on reducing the workload imposed by the indicator-multiload, is not really going to solve the general underlying problem.

I think move all GUI things of the shell (including extensions) outside the compositor thread, in a new process, should solved it, because that ensure that an arbitrary code of an extension can not block the compositor thread.