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 684639 - GtkSpinner animation eats too much CPU
GtkSpinner animation eats too much CPU
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
3.6.1
Depends on:
Blocks:
 
 
Reported: 2012-09-22 22:50 UTC by Bastien Nocera
Modified: 2018-05-02 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Make process_all_updates draw synchronously (1.60 KB, patch)
2012-10-01 08:09 UTC, Alexander Larsson
committed Details | Review
cairo trace of simplified spinner rendering (34.43 KB, application/octet-stream)
2012-10-01 19:23 UTC, Alexander Larsson
  Details

Description Bastien Nocera 2012-09-22 22:50:09 UTC
When restoring an epiphany session with GTK+ 3.5.18, 100% CPU is used, and pages never actually finish loading.
Downgrading to GTK+ 3.5.16 (the previous built version for Fedora) seems to fix the problem.
Comment 1 Matthias Clasen 2012-09-23 03:13:45 UTC
Can you find out where it's spinning ?
Comment 2 Bastien Nocera 2012-09-25 10:27:52 UTC
X is the one using 100% CPU, and the backtraces look like:
  • #0 poll
    from /lib64/libc.so.6
  • #1 _xcb_conn_wait
    from /lib64/libxcb.so.1
  • #2 _xcb_out_send
    from /lib64/libxcb.so.1
  • #3 xcb_writev
    from /lib64/libxcb.so.1
  • #4 _XSend
    at xcb_io.c line 494
  • #5 _XFlush
    at xcb_io.c line 511
  • #6 _XGetRequest
    at XlibInt.c line 1973
  • #7 XRenderComposite
    from /lib64/libXrender.so.1
  • #8 composite
    at cairo-xlib-render-compositor.c line 539
  • #9 composite_opacity
    at cairo-traps-compositor.c line 1616
  • #10 do_unaligned_box
    at cairo-traps-compositor.c line 122
  • #11 composite_opacity_boxes
    at cairo-traps-compositor.c line 1665
  • #12 create_composite_mask
    at cairo-traps-compositor.c line 475
  • #13 clip_and_composite_source
    at cairo-traps-compositor.c line 666
  • #14 clip_and_composite
    at cairo-traps-compositor.c line 1021
  • #15 _cairo_traps_compositor_mask
    at cairo-traps-compositor.c line 2057
  • #16 _cairo_compositor_mask
    at cairo-compositor.c line 106
  • #17 _cairo_surface_mask
    at cairo-surface.c line 1921
  • #18 _cairo_surface_mask
    at cairo-surface.c line 1886
  • #19 _cairo_gstate_mask
    at cairo-gstate.c line 1128
  • #20 _cairo_default_context_paint_with_alpha
    at cairo-default-context.c line 936
  • #21 cairo_paint_with_alpha
    at cairo.c line 2026
  • #22 gtk_css_image_cross_fade_draw
    from /lib64/libgtk-3.so.0
  • #23 _gtk_css_image_draw
    from /lib64/libgtk-3.so.0
  • #24 _gtk_theming_background_render
    from /lib64/libgtk-3.so.0
  • #25 gtk_theming_engine_render_activity
    from /lib64/libgtk-3.so.0
  • #26 gtk_render_activity
    from /lib64/libgtk-3.so.0
  • #27 gtk_spinner_draw
    from /lib64/libgtk-3.so.0
  • #28 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #29 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #30 _g_closure_invoke_va
    at gclosure.c line 840
  • #31 g_signal_emit_valist
    at gsignal.c line 3211
  • #32 g_signal_emit
    at gsignal.c line 3356
  • #33 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #34 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #35 gtk_box_forall
    from /lib64/libgtk-3.so.0
  • #36 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #37 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #38 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #39 _g_closure_invoke_va
    at gclosure.c line 840
  • #40 g_signal_emit_valist
    at gsignal.c line 3211
  • #41 g_signal_emit
    at gsignal.c line 3356
  • #42 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #43 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #44 gtk_notebook_draw
    from /lib64/libgtk-3.so.0
  • #45 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #46 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #47 _g_closure_invoke_va
    at gclosure.c line 840
  • #48 g_signal_emit_valist
    at gsignal.c line 3211
  • #49 g_signal_emit
    at gsignal.c line 3356
  • #50 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #51 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #52 gtk_box_forall
    from /lib64/libgtk-3.so.0
  • #53 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #54 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #55 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #56 _g_closure_invoke_va
    at gclosure.c line 840
  • #57 g_signal_emit_valist
    at gsignal.c line 3211
  • #58 g_signal_emit
    at gsignal.c line 3356
  • #59 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #60 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #61 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #62 gtk_window_draw
    from /lib64/libgtk-3.so.0
  • #63 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #64 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #65 _g_closure_invoke_va
    at gclosure.c line 840
  • #66 g_signal_emit_valist
    at gsignal.c line 3211
  • #67 g_signal_emit
    at gsignal.c line 3356
  • #68 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #69 gtk_widget_send_expose
    from /lib64/libgtk-3.so.0
  • #70 gtk_main_do_event
    from /lib64/libgtk-3.so.0
  • #71 _gdk_window_process_updates_recurse
    from /lib64/libgdk-3.so.0
  • #72 gdk_window_process_updates_internal
    from /lib64/libgdk-3.so.0
  • #73 gdk_window_process_all_updates
    from /lib64/libgdk-3.so.0
  • #74 gtk_container_idle_sizer
    from /lib64/libgtk-3.so.0
  • #75 gdk_threads_dispatch
    from /lib64/libgdk-3.so.0
  • #76 g_main_dispatch
    at gmain.c line 2715
  • #77 g_main_context_dispatch
    at gmain.c line 3219
  • #78 g_main_context_iterate
    at gmain.c line 3290
  • #79 g_main_context_iteration
    at gmain.c line 3351
  • #80 g_application_run
    at gapplication.c line 1607
  • #81 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 _xcb_conn_wait
    from /lib64/libxcb.so.1
  • #2 _xcb_out_send
    from /lib64/libxcb.so.1
  • #3 xcb_writev
    from /lib64/libxcb.so.1
  • #4 _XSend
    at xcb_io.c line 494
  • #5 XRenderCompositeTrapezoids
    from /lib64/libXrender.so.1
  • #6 composite_traps
    at cairo-xlib-render-compositor.c line 1634
  • #7 clip_and_composite
    at cairo-traps-compositor.c line 1038
  • #8 clip_and_composite_polygon
    at cairo-traps-compositor.c line 1576
  • #9 _cairo_traps_compositor_fill
    at cairo-traps-compositor.c line 2229
  • #10 _cairo_compositor_fill
    at cairo-compositor.c line 199
  • #11 _cairo_xlib_surface_fill
    at cairo-xlib-surface.c line 1385
  • #12 _cairo_surface_fill
    at cairo-surface.c line 2084
  • #13 _cairo_surface_fill
    at cairo-surface.c line 2057
  • #14 _cairo_gstate_fill
    at cairo-gstate.c line 1294
  • #15 _cairo_default_context_fill
    at cairo-default-context.c line 1010
  • #16 cairo_fill
    at cairo.c line 2201
  • #17 gtk_css_image_gradient_draw
    from /lib64/libgtk-3.so.0
  • #18 _gtk_css_image_draw
    from /lib64/libgtk-3.so.0
  • #19 gtk_css_image_cross_fade_draw
    from /lib64/libgtk-3.so.0
  • #20 _gtk_css_image_draw
    from /lib64/libgtk-3.so.0
  • #21 _gtk_theming_background_render
    from /lib64/libgtk-3.so.0
  • #22 gtk_theming_engine_render_activity
    from /lib64/libgtk-3.so.0
  • #23 gtk_render_activity
    from /lib64/libgtk-3.so.0
  • #24 gtk_spinner_draw
    from /lib64/libgtk-3.so.0
  • #25 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #26 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #27 _g_closure_invoke_va
    at gclosure.c line 840
  • #28 g_signal_emit_valist
    at gsignal.c line 3211
  • #29 g_signal_emit
    at gsignal.c line 3356
  • #30 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #31 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #32 gtk_box_forall
    from /lib64/libgtk-3.so.0
  • #33 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #34 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #35 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #36 _g_closure_invoke_va
    at gclosure.c line 840
  • #37 g_signal_emit_valist
    at gsignal.c line 3211
  • #38 g_signal_emit
    at gsignal.c line 3356
  • #39 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #40 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #41 gtk_notebook_draw
    from /lib64/libgtk-3.so.0
  • #42 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #43 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #44 _g_closure_invoke_va
    at gclosure.c line 840
  • #45 g_signal_emit_valist
    at gsignal.c line 3211
  • #46 g_signal_emit
    at gsignal.c line 3356
  • #47 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #48 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #49 gtk_box_forall
    from /lib64/libgtk-3.so.0
  • #50 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #51 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #52 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #53 _g_closure_invoke_va
    at gclosure.c line 840
  • #54 g_signal_emit_valist
    at gsignal.c line 3211
  • #55 g_signal_emit
    at gsignal.c line 3356
  • #56 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #57 gtk_container_propagate_draw
    from /lib64/libgtk-3.so.0
  • #58 gtk_container_draw
    from /lib64/libgtk-3.so.0
  • #59 gtk_window_draw
    from /lib64/libgtk-3.so.0
  • #60 _gtk_marshal_BOOLEAN__BOXEDv
    from /lib64/libgtk-3.so.0
  • #61 gtk_widget_draw_marshallerv
    from /lib64/libgtk-3.so.0
  • #62 _g_closure_invoke_va
    at gclosure.c line 840
  • #63 g_signal_emit_valist
    at gsignal.c line 3211
  • #64 g_signal_emit
    at gsignal.c line 3356
  • #65 _gtk_widget_draw_internal
    from /lib64/libgtk-3.so.0
  • #66 gtk_widget_send_expose
    from /lib64/libgtk-3.so.0
  • #67 gtk_main_do_event
    from /lib64/libgtk-3.so.0
  • #68 _gdk_window_process_updates_recurse
    from /lib64/libgdk-3.so.0
  • #69 gdk_window_process_updates_internal
    from /lib64/libgdk-3.so.0
  • #70 gdk_window_process_all_updates
    from /lib64/libgdk-3.so.0
  • #71 gtk_container_idle_sizer
    from /lib64/libgtk-3.so.0
  • #72 gdk_threads_dispatch
    from /lib64/libgdk-3.so.0
  • #73 g_main_dispatch
    at gmain.c line 2715
  • #74 g_main_context_dispatch
    at gmain.c line 3219
  • #75 g_main_context_iterate
    at gmain.c line 3290
  • #76 g_main_context_iteration
    at gmain.c line 3351
  • #77 g_application_run
    at gapplication.c line 1607
  • #78 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 _xcb_conn_wait
    from /lib64/libxcb.so.1
  • #2 _xcb_out_send
    from /lib64/libxcb.so.1
  • #3 xcb_writev
    from /lib64/libxcb.so.1
  • #4 _XSend
    at xcb_io.c line 494
  • #5 _XFlush
    at xcb_io.c line 511
  • #6 XFlush
    at Flush.c line 39
  • #7 gdk_window_process_all_updates
    from /lib64/libgdk-3.so.0
  • #8 gtk_container_idle_sizer
    from /lib64/libgtk-3.so.0
  • #9 gdk_threads_dispatch
    from /lib64/libgdk-3.so.0
  • #10 g_main_dispatch
    at gmain.c line 2715
  • #11 g_main_context_dispatch
    at gmain.c line 3219
  • #12 g_main_context_iterate
    at gmain.c line 3290
  • #13 g_main_context_iteration
    at gmain.c line 3351
  • #14 g_application_run
    at gapplication.c line 1607
  • #15 main

Comment 3 Benjamin Otte (Company) 2012-09-26 10:06:54 UTC
Some additional information:

GDK_RENDERING=image fixes it, so our animations are hitting a GPU driver issue.
The GPU in question is Intel and it seems to be F18 only, my F17 is fine.
I've heard people claiming F18 shipping debug kernels might contribute, but I lack enough clue about the graphics stack to have any guesses in that area.
Comment 4 Bastien Nocera 2012-09-27 22:16:39 UTC
Problem seems fixed by using a non-debug kernel.
Comment 5 Alexander Larsson 2012-10-01 07:59:43 UTC
I don't think this is fixes as is, we still have no rate limiting in the client when rendering is expensive. I.e. the client will keep pushing new redraw commands every 40msec or whatever, potentially building up a large queue of drawing ops in the XServer such that it will not be able to "catch up" with the client. This essentially locks up X, as not even the VM will be able to do anything.

The correct approach is imho to XSync after drawing so that we never animate until the current frame has been drawn. This way we avoid all kinds of issues similar to this particular Intel rendering issue.
Comment 6 Alexander Larsson 2012-10-01 08:09:08 UTC
Created attachment 225473 [details] [review]
Make process_all_updates draw synchronously

By calling XSync in _gdk_x11_display_after_process_all_updates we
effectively make gdk rendering sync, which avoids problems with the
client animations running faster than the Xserver rendering, thus
filling up the X rendering pipes and essentially "locking up" the
Xserver (i.e. you can't even close the offending window because the
WM is starved too).

I verified this worked by making GtkSpinner paint multiple times on my
intel driver (which has some issue making this rendering slow atm),
and without this patch i get severe lag where even window dragging
stops for 5 seconds when i drag the mouse around. However, with the
patch everything is smooth.
Comment 7 Alexander Larsson 2012-10-01 08:19:43 UTC
CCing owen for a quick check.
Comment 8 Chris Wilson 2012-10-01 10:35:06 UTC
XSync under normal circumstances will not flush the GPU render queue (it is likely to have that side-effect under a compositor though, alas). The round-trip will serialise with the slow fallbacks that the driver would appear to be hitting. The question is whether you really want to workaround a driver bug by impacting all users of your toolkit.

If you want to perform some ratelimiting, insert an event in _gdk_x11_display_after_process_all_updates() and block expose events until it is returned (or better until the previous one is returned). (To insert such events into the command stream without using xcb, create a dummy window and use SendEvent and hookup a custom callback to increment the seqno.)
Comment 9 Alexander Larsson 2012-10-01 14:27:11 UTC
We already have _gdk_x11_roundtrip_async() to do a roundtrip. Whats the practical difference though? We'd block less on high latency links, but even with an async version the "visual" latency would be essentially the same, would it not? The only difference would be if rendering is slow *and* calculating the next frame is also slow. Then doing the XSync() async will parallelize the two.
Comment 10 Owen Taylor 2012-10-01 15:21:29 UTC
As long as we're doing the synchronization once per frame and at the end of all drawing, I think the practical difference between XSync() and doing some fancy async thing is pretty small - we generally don't want to start processing events or updating animations for the next frame until we know that the previous frame "completed".

In terms of whether XSync() a) flushes the GPU buffers to the kernel b) waits for rendering to complete - I'd say let's fix the problem that we're having - requests queueing up before processing by the X server - and not worry about problems we're not having at the moment - drawing piling up as GPU command buffers inside the X server or piling up in GPU pipeline. There will be a more comprehensive framework for this in 3.8.

The patch looks fine to me.
Comment 11 Zeeshan Ali 2012-10-01 18:28:34 UTC
FWIW, this also makes gnome-boxes unusable for me.
Comment 12 Cosimo Cecchi 2012-10-01 19:09:46 UTC
This also seems to negatively impact gnome-documents when there's a spinner animation running.
Comment 13 Jasper St. Pierre (not reading bugmail) 2012-10-01 19:17:17 UTC
(In reply to comment #8)
> XSync under normal circumstances will not flush the GPU render queue (it is
> likely to have that side-effect under a compositor though, alas). The
> round-trip will serialise with the slow fallbacks that the driver would appear
> to be hitting.

If the is that we're hitting slow fallbacks, can we fix that instead? I'd be curious to figure out what's happening here.
Comment 14 Alexander Larsson 2012-10-01 19:23:46 UTC
Created attachment 225526 [details]
cairo trace of simplified spinner rendering

This cairo trace is from a simplified version of the spinner rendering (rectangles, not circles) that still seems to exhibit extremely bad performance:

cairo-perf-trace /tmp/spin.27363.trace 
[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]      xcb                   spin.27363    1.402    1.410   0.44%    5/6
[  0]     xlib                   spin.27363    1.743    1.746   0.09%    4/6
[ # ]    image: pixman 0.26.2
[  0]    image                   spin.27363    0.066    0.066   0.05%    4/6
[ # ]  image16: pixman 0.26.2
[  0]  image16                   spin.27363    0.068    0.068   0.20%    6/6
Comment 15 Chris Wilson 2012-10-01 20:35:25 UTC
Looks like it tricks UXA into doing lots and lots of short rendering, with the cost of each magnified by the debug kernel. SNA in this case on par with image, not surprising as it decides to keep the workload on the CPU as it is too small to justify the overhead of setting up the GPU.
Comment 16 Alexander Larsson 2012-10-02 09:37:52 UTC
I did some testing on remote Gtk+ with the XSync patch on a lan with artificial 50msec outgoing latency on both machines. Interactivity wise there was not much difference in the "static" case.

In the case with animations (i tried the animating background example in gtk3-demo) there were obvious differences. Without XSync the animation was very smooth in that it sent each frame. However, this caused interactivity problems as the pipe was full of rendering ops or something, for instance editing text was more laggy. With XSync the animation made much larger jumps, but interactivity was better.

Note that this example is slightly artificial in that the bandwidth is very high. In a more common high-latency case the bandwidth would also be lower, probably causing even more interactivity issues in the non-XSync case, but not noticably affecting the XSynced case (assuming each "frame" is not *that* large).
Comment 17 Benjamin Otte (Company) 2012-10-02 09:52:43 UTC
I'd say go for it now and if someone finds obvious problems with it we can revisit the patch. (And of course, if someone sends a better patch.)
Comment 18 Alexander Larsson 2012-10-02 11:23:13 UTC
Comment on attachment 225473 [details] [review]
Make process_all_updates draw synchronously

Attachment 225473 [details] pushed as 83c66c9 - Make process_all_updates draw synchronously
Comment 19 Benjamin Otte (Company) 2012-10-02 12:36:11 UTC
I just implemented gradient transitions in git master. This has the side effect of improving the performance for this case a lot, because we avid the expensive cross-fade code, but instead compute the cross-faded gradient in advance.

(Also, new feature in a stable series, I always wanted to do that!)
Comment 20 Milan Crha 2012-10-19 09:26:55 UTC
I updated gtk3 in my F18 virtual box with fallback mote to 3.6.1 and the gtk3-demo -> Spinner still eats too much of CPU, about 8%, thus I do not think this is fixed.
Comment 21 Milan Crha 2012-10-23 08:16:19 UTC
One more observation with gtk3-3.6.1: Evolution uses gcr-prompt for password prompts in a way that on "Continue" it keeps the password prompt opened, whcih shows the spinner in front of the "Continue" button, even the whole dialog is disabled. In gnome-shell, when I get into this spinning Continue state, while evolution is testing the password against the server, the CPU goes high again. Hence I'm reopening this.
Comment 22 Chris Wilson 2012-10-23 08:30:49 UTC
Let's not be so vague. Where is the time being spent? What is you acceptance criteria?
Comment 23 Milan Crha 2012-10-23 12:20:17 UTC
I'm not sure what's vague on comment #21, I gave application and such. Nonetheless, I have easier reproducer:
a) boot to gnome-shell
b) run gtk3-demo->Spinner, or Images, or other demos where anything animates
   gnome-shell and Xorg (according to 'top') are using the CPU most,
   just behind them is gtk3-demo, with almost 10% of CPU

My acceptance criteria is easy, gtk3-3.4.x did the same animation (from the user's point of view) with no indication on CPU usage, while the 3.6.x behaves insanely here. From my point of view, animations are nice, but they should be below IDLE in the priority queue, thus the application, if needs IDLE, can get to it before the animation, because the animation is just to show that the UI thread is not dead/blocked, and for nothing else. In fact, the animation can block delivery of IDLE, if I understand it correctly.

This is within a virtual machine of Fedora 18 installation, run in Fedora 17.
Comment 24 Milan Crha 2012-11-19 11:54:49 UTC
I've installed gtk3-3.6.1-1.fc18.x86_64 now, on a real machine, and gtk3-demo->Spinners eats about 4-8% of CPU when animating those two spinners. On the other hand, the Tree View->List store doesn't suffer of this issue (there is one spinner animating). The Pixbufs demo is also mostly fine (I see occasional jumps to 4%, but nothing constant).
Comment 25 Wolfgang Pirker 2013-02-24 19:35:06 UTC
I experienced high CPU consumption when using an active spinner as well.

My gtk3 version: 
gtk3-3.6.4-1.fc18.i686

With an active spinner the CPU consumption of my GTK app jumps 11% up, from 0%-1%. I decided on using an appropriate animated GIF picture instead as spinner - this needs only 1-2%. 

Active spinners are also a pain when putting these into UI files in Anjuta. Anjutas CPU consumption jumps then to about 60% (from 1% before that).
Comment 26 Matthias Clasen 2014-05-22 02:19:20 UTC
I think the frame clock and size limiting the spinner have addressed this problem
Comment 27 Milan Crha 2018-03-27 07:30:18 UTC
(In reply to Matthias Clasen from comment #26)
> I think the frame clock and size limiting the spinner have addressed this
> problem

No, it didn't. I still see high CPU usage with gtk3-demo->Spinner with installed gtk3-3.22.26-2.fc27.x86_64.
Comment 28 Milan Crha 2018-03-27 10:58:28 UTC
I can share a little test program, which adds multiple GtkSpinner-s into the window, where it can be easily reproduced. There is expect some CPU usage when it comes to 100s of spinners in the window (frankly, I do not expect any application needing so many of them at one time), but it's good for measuring the performance. I've been even able to reproduce a delay (when I've been lucky then only delay, for example 9 seconds, other time the delivery could be left stuck in the queue and not finished at all) in g_idle_add() callback receiving when there had been like 125 GtkSpinners spinning in the window, but I've not been able to reproduce it consistently between various desktop environments (I tried Plasma, MATE, GNOME on Wayland and GNOME on X.org (where the last had disabled spinning completely for some reason)). That test application contains also an ESpinner, which is used in Evolution, which doesn't cause that significant CPU usage (comparing 25 spinners of one or the other type, not both at the same time). Te ESpinner uses the old method of the "busy" animation, which has its own pros and cons with compare to the GtkSpinner, but it's sufficient for the Evolution itself.
Comment 29 Adam Williamson 2018-03-27 16:50:08 UTC
See also http://bugzilla.gnome.org/show_bug.cgi?id=732199 .
Comment 30 Daniel Boles 2018-04-09 13:32:06 UTC
and https://gitlab.gnome.org/GNOME/gtk/issues/166 to have it stop animating when hidden, which would, if not resolve, at least mask this problem in suitable cases

fwiw, with `gtk3-demo` on win32, simply running the Spinner test and starting the 2 in there brings CPU usage from 0 to a reliable 2~3% (i5-3210M) - better than above figures, I guess, but probably still a bit excessive for all it's doing.

Milan: You could define what you mean by "high CPU usage" and what you would consider 'not high'. It's vague what the problem is now, especially given that its effect is probably (at least artificially) reduced by higher-performance CPUs being more common today.
Comment 31 Adam Williamson 2018-04-09 16:59:50 UTC
"and https://gitlab.gnome.org/GNOME/gtk/issues/166 to have it stop animating when hidden, which would, if not resolve, at least mask this problem in suitable cases"

note this wouldn't help the anaconda case, as it's visible there. anaconda doesn't really want anything fancy, just some kind of simple animation to indicate 'stuff is happening', but they want to use something standardized that they don't have to maintain.
Comment 32 Milan Crha 2018-04-10 10:44:48 UTC
(In reply to Daniel Boles from comment #30)
> Milan: You could define what you mean by "high CPU usage" and what you would
> consider 'not high'. It's vague what the problem is now, especially given
> that its effect is probably (at least artificially) reduced by
> higher-performance CPUs being more common today.

Running a GNOME shell session on Wayland with installed:
gnome-shell-3.26.2-4.fc27.x86_64
mutter-3.26.2-2.fc27.x86_64
gtk3-3.22.26-2.fc27.x86_64
in a virtual machine and in it a terminal where I ran `top` and in a different tab gtk3-demo->Spinner, where two spinners are spinning. The `top` itself shows gnome-shell being in more that 30% of CPU, some kworker at 6.3% and gtk3-demo also around 6% of CPU.

There are only two spinners, that should not be visible in `top` at all.

When I stop the Spinner demo gnome-shell goes down to ~1% of CPU and gtk3-demo is at 0%.

Using my test application with a different animation (not GtkSpinner), also with two animated squares of 16x16, I see gnome-shell in around 10-20% of CPU and the test application in less than 2% of CPU. The gnome-shell usage is still quite high from my point of view, which may or may not be related to gnome-shell itself, but at least the application itself is lower than 1/3 of the similar gtk-3-demo functionality (GtkSpinner).

Maybe testing this in a virtual machine is not ideal, I see some downgrades in performance in F28 only when moving mouse in gdm and gnome-shell, I do not know.
Comment 33 GNOME Infrastructure Team 2018-05-02 15:32:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/408.