Bug 1204242

Created attachment 1004562 [details]
updates.img to disable spinner animation

This is an updates.img to disable spinner animation. Please have a look at your guest+host CPU utilization, measure the installation time. Then try again with this updates image. It should be considerably faster and both host and guest CPU usage should be considerably lower.

Note upstream now seems to be actively working on this:

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

so we may see a resolution there. It's also worth noting that GNOME has a thing where it disables animation if it doesn't think your hardware is up to it (not sure if it's just llvmpipe vs. hardware or if it's something more sophisticated), so on Workstation live installs, we don't have this problem. But anaconda doesn't have the same logic. I'm guessing it's in gnome-settings-daemon.

(In reply to awilliam from comment #2)
> Note upstream now seems to be actively working on this:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=732199

Don't get your hopes up. This is not an easy thing to fix, it requires a considerable refactoring of the size allocation machinery in GTK+. Nobody is working on that at the moment.

Stealing evolution's spinner is pretty easy, turns out, but this sure is a dumb problem to have

Stealing evolution's spinner is too weird. It's a gtk widget causing the problem, so reassigning to gtk.

(In reply to Kamil Páral from comment #0)
> * Please disable gtk animations when running inside VM. One possible way is
> to include gnome-settings-daemon in netinst, which handles it. A second
> approach is to run `systemd-detect-virt` and if it detects a VM, then create
> /etc/gtk-3.0/settings.ini with this contents:
> > [Settings]
> > gtk-enable-animations=0
> before starting anaconda gui.

That disables all the stack and overlay animations too, though. We want those.

*** Bug 1201201 has been marked as a duplicate of this bug. ***

Hi David, thanks for looking into this. There already is a bug reported against gtk3, I don't think it makes much sense to reassign this. I reported it specifically against anaconda to ask for some temporary solution until the gtk bug is fixed. If you decided to wait for gtk fix and not do anything about it in the meantime, let's close this as WONTFIX. However, if you decide to go this route, we can be pretty sure that this won't get fixed before F22 release.

Is the spinner so necessary? Or, are those other animations in a VM so necessary?

(In reply to Kamil Páral from comment #7)

> Is the spinner so necessary? 

Without it people will think anaconda has locked up while running the %post scripts, so kinda.

> Or, are those other animations in a VM so necessary?

No, but they're nice to have from a usability point of view, since it helps explain the non-linear hub/spoke relationship.

"That disables all the stack and overlay animations too, though. We want those."

You already don't get them in Workstation live installs, because GNOME does this (disables animation) when hardware acceleration is not available.

(In reply to awilliam from comment #9)
> "That disables all the stack and overlay animations too, though. We want
> those."
> 
> You already don't get them in Workstation live installs, because GNOME does
> this (disables animation) when hardware acceleration is not available.

I know. I really wish they wouldn't!

*** Bug 1278189 has been marked as a duplicate of this bug. ***

This is still a problem, and has just been rediscovered *three years later* by Chris Murphy:

https://lists.fedoraproject.org/archives/list/desktop%40lists.fedoraproject.org/message/XUWK4CV6WONUEHN2VMJVHMSDBR3NWSZS/

we really need to do something about this, it's fairly absurd that this has been sucking up resources and making VM installs slow *this whole time*.

Problems with GtkSpinner will not cause gnome-shell to use 40x as much CPU as the GTK+ process (anaconda) - I think something else is going on here - I guess some interaction between the qxl driver and gnome-shell running (under wayland?)

(In reply to Adam Williamson from comment #12)
> This is still a problem, and has just been rediscovered *three years later*
> by Chris Murphy:
> 
> https://lists.fedoraproject.org/archives/list/desktop%40lists.fedoraproject.
> org/message/XUWK4CV6WONUEHN2VMJVHMSDBR3NWSZS/
> 
> we really need to do something about this, it's fairly absurd that this has
> been sucking up resources and making VM installs slow *this whole time*.
Definitely - but is this really an Anaconda issue ? We are just using a spinner widget provided by GTK. 

Comment 7 mentions an upstream Gnome/GTK bug (https://bugzilla.gnome.org/show_bug.cgi?id=732199) that is marked as fixed. So maybe another upstream bug needs to be opened or this bug reassigned to GTK ?

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

For fun and profit, I retested this with F31 installation media on F30 VM host. For Server DVD, the updates.img from attachment 1004562 [details] was used to disable the spinner animation. For Workstation Live, I used "gsettings set org.gnome.desktop.interface enable-animations false" command.

Server DVD:
1 cpu, spinner disabled: 178 s
1 cpu, spinner enabled: 210 s  (+ 18%)
2 cpu, spinner disabled: 149 s
2 cpu, spinner enabled: 167 s  (+ 12%)

Workstation Live:
1 cpu, spinner disabled: 286 s
1 cpu, spinner enabled: 500 s  (+ 75%)
2 cpu, spinner disabled: 249 s
2 cpu, spinner enabled: 316 s  (+ 27%)

So, compared to comment 0, the penalty is still quite noticeable for Anaconda installer environment (DVD, netinst), but much lower than it used to be. However, it also start affecting Live images (GTK no longer skips animations in VMs), and especially with just a single allocated CPU, the penalty is very noticeable in day-to-day testing.

Kamil, would you be open to repeating your test with some changes? I have appended the following line to anaconda-gtk.css:

spinner { animation-timing-function: steps(4); }

I suspect reducing the number of updates to 4 might make the overhead nearly go away... at a corresponding sacrifice of aesthetic value.

If that does help, perhaps you could also try and see what happens with 12? To me the spinner seems still acceptably beautiful at 12 FPS, which might be less than the GTK default "draw as often as possible". But the documentation seems to suggest 12 is some internal timing-related value too, so I'm not putting too much hope into that.

I'll attach update images against current Rawhide with the changes described above.

Created attachment 1640431 [details]
Updates image to make the spinner repaint at 4 FPS

Created attachment 1640433 [details]
Updates image to make the spinner repaint at 12 FPS

Hi Vladimir, that's a great idea! 

Those updates.img's were probably created against the development version of anaconda? I get a traceback when I apply it against F31 Workstation Live:

[liveuser@localhost-live ~]$ liveinst --updates=https://bugzilla.redhat.com/attachment.cgi?id=1640431
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 60623  100 60623    0     0  54176      0  0:00:01  0:00:01 --:--:-- 54176
643 blocks
Starting installer, one moment...
Traceback (most recent call last):
  File "/sbin/anaconda", line 247, in <module>
    from pyanaconda import startup_utils
  File "/tmp/updates/pyanaconda/startup_utils.py", line 36, in <module>
    from pyanaconda import network
  File "/tmp/updates/pyanaconda/network.py", line 40, in <module>
    from pyanaconda.modules.common.constants.services import NETWORK, TIMEZONE
  File "/tmp/updates/pyanaconda/modules/common/constants/services.py", line 19, in <module>
    from pyanaconda.core.dbus import SystemBus, DBus
ModuleNotFoundError: No module named 'pyanaconda.core.dbus'


But no problem, I adjusted anaconda-gtk.css manually. I'm now on F31 host, so I had to retest even the default results. Here are my numbers:

Workstation Live:
1 cpu, spinner disabled: 320 s
1 cpu, spinner 4 fps: 334 s  (+ 4%)
1 cpu, spinner 12 fps: 366 s  (+ 14%)
1 cpu, spinner enabled: 565 s  (+ 77%)

The 12 fps spinner seems like a reasonable compromise that doesn't look bad and lowers the overhead substantially.

Thank you for the tests, Kamil! I made a pull request, let's see what the rest of the team thinks: https://github.com/rhinstaller/anaconda/pull/2240


(Note to self: To play with the CSS interactively, do GTK_DEBUG=interactive glade and then fiddle with stuff. Spinner needs re-enabling to apply changes.)

We could further reduce the number of steps with a different icon. I have open a new bug for the adwaita-icon-theme (see the bug 1779130).

Kamil, the current compromise that we agree could be merged immediately is making the animation go at 24 FPS. Would that help you? I've interpolated the numbers above which gives me an estimate of 128% for Workstation Live. (Somewhat curiously, the interpolation also predicts the unrestricted rate of repaints is about 65 Hz.)

As 24/65 should be more than 60% better, trying more gymnastics to gain a few more % is probably not worth it. That said, there are some more options to try in case you're bored. Or maybe let's talk about how you do the measurements?

----

For the sake of completeness...

First alternative is to make the animation cycle longer, but at the 12 FPS. This helps the visual jerkiness by making the movement less noticeable. This should give same numbers as the steps(12) variant.

spinner:checked { animation: spin 10s steps(120) infinite; }

In practice the timing seems to be susceptible to random slowdowns due to other processes randomly consuming more CPU, which gets exaggerated at low update rates, so it is randomly ugly and useless anyway.

Second possibility is to use an animation that stays put most of the time. It's debatable if this does save on the CPU or not, though. (I'd love to find out.) It would look something like this...

@keyframes anaconda_spin {
 0% { -gtk-icon-transform: none; }
 66% { -gtk-icon-transform: none; }
 100% { -gtk-icon-transform: rotate(180deg); }
}

spinner {
 -gtk-icon-source: -gtk-icontheme("emblem-synchronizing-symbolic");
}

spinner:checked {
 animation: anaconda_spin 5s ease-in-out infinite;
}

I merged the pull request so the timing should be down to ca. +28% for Workstation Live.

(In reply to Vladimír Slávik from comment #24)
> Or maybe let's talk about how you do the
> measurements?

I simply boot F31 Workstation Live in a VM, make any spinner adjustments if needed, then start anaconda and configure the installation. I measure the time using an external application from the moment I click Begin installation until the moment the installation is fully finished and a Finish installation button appears.

> the current compromise that we agree could be merged immediately is
> making the animation go at 24 FPS.

1 cpu, spinner disabled: 322 s
1 cpu, spinner 24 fps: 438 s  (+ 36%)

> First alternative is to make the animation cycle longer, but at the 12 FPS.
> This helps the visual jerkiness by making the movement less noticeable. This
> should give same numbers as the steps(12) variant.
> 
> spinner:checked { animation: spin 10s steps(120) infinite; }

1 cpu, spinner 12 fps slower: 372 s  (+ 16%)

> Second possibility is to use an animation that stays put most of the time.
> It's debatable if this does save on the CPU or not, though. (I'd love to
> find out.) It would look something like this...
> 
> @keyframes anaconda_spin {
>  0% { -gtk-icon-transform: none; }
>  66% { -gtk-icon-transform: none; }
>  100% { -gtk-icon-transform: rotate(180deg); }
> }
> 
> spinner {
>  -gtk-icon-source: -gtk-icontheme("emblem-synchronizing-symbolic");
> }
> 
> spinner:checked {
>  animation: anaconda_spin 5s ease-in-out infinite;
> }

1 cpu, spinner emblem-synchronizing-symbolic: 370 s  (+ 15%)


It seems that the spinner load is directly proportional to the number of animations over a time period. The most reasonable thing is to have a mostly static spinner that makes a short animation from time to time (like the emblem-synchronizing-symbolic above). There are "spinners" (progress indicators) out there which do exactly this. Too bad GTK goes a different way at the moment :-/

Thanks a lot for working on this. Even the 24 FPS spinner is still a considerable improvement for the installation times.

Kamil, sorry to keep pestering you, but there is one final question. Do you consider this bug "closeable" based on the changes done?. If not, please state it explicitly. Obviously some of us are itching to close the bug ;-)

Oh sure. Thank you very much for implementing a decent workaround for the issue!

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Released with F32.