After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732199 - Animating a GtkSpinner causes surprisingly high CPU usage
Animating a GtkSpinner causes surprisingly high CPU usage
Product: gtk+
Classification: Platform
Component: Class: GtkStyleContext
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
: 739707 746535 (view as bug list)
Depends on:
Reported: 2014-06-25 03:04 UTC by Adam Williamson
Modified: 2018-04-09 08:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

sysprof profile while reproducing the issue (92.43 KB, application/x-xz)
2014-06-25 03:05 UTC, Adam Williamson

Description Adam Williamson 2014-06-25 03:04:15 UTC
From , 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.
Comment 1 Adam Williamson 2014-06-25 03:05:47 UTC
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.
Comment 2 Adam Williamson 2014-06-25 03:08:48 UTC
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.
Comment 3 Adam Williamson 2014-06-25 22:41:51 UTC
still reproducible - in fact, slightly worse - with gtk3-3.13.3-1.fc21.x86_64 .
Comment 4 Adam Williamson 2014-10-11 16:48:56 UTC
Still reproducible with gtk3-3.14.2-1.fc21.x86_64 .
Comment 5 Matthias Clasen 2014-11-07 22:08:37 UTC
*** Bug 739707 has been marked as a duplicate of this bug. ***
Comment 6 Emmanuele Bassi (:ebassi) 2015-03-20 15:55:28 UTC
Fairly well reproducible; the issue is not tied to a specific graphics driver: the spinner is just queueing relayouts at 60 fps.
Comment 7 Emmanuele Bassi (:ebassi) 2015-03-20 15:55:33 UTC
*** Bug 746535 has been marked as a duplicate of this bug. ***
Comment 8 Emmanuele Bassi (:ebassi) 2015-03-20 16:06:25 UTC
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
--- a/gtk/gtkcssstylepropertyimpl.c
+++ b/gtk/gtkcssstylepropertyimpl.c
@@ -1523,7 +1523,7 @@ _gtk_css_style_property_init_properties (void)
-                                          GTK_CSS_AFFECTS_ICON | GTK_CSS_AFFECTS_CLIP,
+                                          GTK_CSS_AFFECTS_ICON,

But that may very well end up creating artefacts when rendering the spinner. I'm just leaving it here from an IRC conversation.
Comment 9 Jean-François Fortin Tam 2015-03-20 18:21:58 UTC
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.
Comment 10 Matthias Clasen 2015-03-20 18:33:01 UTC
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.
Comment 11 Kamil Páral 2015-04-30 08:56:14 UTC
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.
Comment 12 2015-11-04 23:04:57 UTC
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? 

Comment 13 Kamil Páral 2015-11-05 13:15:56 UTC
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.
Comment 14 Kamil Páral 2015-12-15 13:18:26 UTC
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?
Comment 15 Matthias Clasen 2015-12-15 18:28:20 UTC
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.