GNOME Bugzilla – Bug 732199
Animating a GtkSpinner causes surprisingly high CPU usage
Last modified: 2018-04-09 08:39:02 UTC
From https://bugzilla.gnome.org/show_bug.cgi?id=732180 , it seems to have become clear that simply displaying a GtkSpinner object causes surprisingly high CPU usage on my system.
System is running Fedora Rawhide, with gtk3-3.13.2-5.fc21.x86_64 . Using X, not Wayland. GNOME Shell. The graphics adapter is an NVIDIA GeForce 9600 GT - that's an nv50 generation card, PCI ID 10de:0622. Using nouveau.
If I run gtk3-demo and simply launch the Spinner demo, I see CPU usage run from normal 'background' levels to significant usage distributed across all cores. htop shows Xorg.bin as using around 50%, gtk3-demo as using about 44%, and gnome-shell using around 25%. As soon as I stop the Spinner demo playing, usage drops right back down to 'background' levels.
Created attachment 279165 [details]
sysprof profile while reproducing the issue
Here's a sysprofile log while reproducing the issue. I started the profile, let it sit without starting the spinner for ~10 seconds to set a baseline, then ran the spinner for ~10 seconds, then stopped the spinner and ran for another ~10 seconds before stopping the profile.
Doing the same thing on a laptop with Intel graphics doesn't display anywhere near the same level of CPU usage (gtk3-demo ramps up a bit, but only to like 7-10%), so there seems to be a nouveau element to this.
still reproducible - in fact, slightly worse - with gtk3-3.13.3-1.fc21.x86_64 .
Still reproducible with gtk3-3.14.2-1.fc21.x86_64 .
*** Bug 739707 has been marked as a duplicate of this bug. ***
Fairly well reproducible; the issue is not tied to a specific graphics driver: the spinner is just queueing relayouts at 60 fps.
*** Bug 746535 has been marked as a duplicate of this bug. ***
According to Benjamin, the hacky way to "fix" the issue is:
diff --git a/gtk/gtkcssstylepropertyimpl.c b/gtk/gtkcssstylepropertyimpl.c
index 45fa695..9b8f590 100644
@@ -1523,7 +1523,7 @@ _gtk_css_style_property_init_properties (void)
- GTK_CSS_AFFECTS_ICON | GTK_CSS_AFFECTS_CLIP,
But that may very well end up creating artefacts when rendering the spinner. I'm just leaving it here from an IRC conversation.
FWIW in 739707 where I had my own sysprof, I was running on an Intel Ironlake i7, so not a nouveau or radeon issue per se.
It is well known what the problem is here.
As Emmanuele says: queueing relayouts at 60 fps.
Unfortunately, a proper fix for this requires a considerable reworking of the GTK+ layout machinery.
Here's an example of issues this bug causes in gtk applications:
Evolution already introduced its own spinner. Anaconda has been at least considering a similar approach, or avoiding using the spinner (not sure how it will turn out in the end).
If it is possible, please try to fix this soon. Thank you.
So this bug still exists and is still causing high CPU usage.
It is still making GTK nearly unuseable on KVM virtualised guests.
and there must be _millions_ of such installations now.
The pointless spinner updates gobble up all the CPU cycles that the Host machine manager will provide. :-(
e.g. 200% CPU in a dual virtual setup.
Maybe there is some progress on this, and it is just not visible here?
Perhaps someone could add a situation update?
I talked to Company on IRC:
<Company> git master has seen some fixes for that
<Company> I have not tested them in kvm or on any resource-constrained systems though, so no idea about the effect
The fixes should appear in gtk+ 3.19.2.
I have tested F23 netinst vs today's Rawhide boot.iso, and I see substantial CPU decrease in the Rawhide case (Xorg used to take about 70% of CPU, now it takes about 4%). So this is great.
On the other hand, I compared GNOME3 desktop from F23 (gtk3-3.18.6-1.fc23.x86_64) and Rawhide (gtk3-3.19.4-1.fc24.x86_64). Both in VM, using X11, with nodebug kernels, animations enabled using gtk-inspector. I see no change in CPU usage, gnome-shell takes about 25% of CPU when the spinners are animated, Xorg takes about 5%. No change.
I wonder whether this has been fixed in gtk (so that anaconda installer using metacity experiences a large improvement), but there is yet another issue in gnome-shell which prevents us from seeing any improvement in that environment?
Sounds to me like the GTK+ problem is fixed. If the shell does not do well with 60fps in a vm, that is a separate issue that should be filed separately.
See also https://bugzilla.gnome.org/show_bug.cgi?id=684639 . Per recent testing, this seems to be still a problem: