GNOME Bugzilla – Bug 321444
Immediately update GtkImage's animation frames.
Last modified: 2005-11-16 14:41:43 UTC
One if the few use cases for using animations is to indicate busyness of some sort. However, if the busyness is caused by an idle function, GtkImage's animation will stop being animated if the idle/timeout function has a priority of less than GDK_PRIORITY_REDRAW. Attached patch adds gdk_window_process_updates() to gtkimage.c(animation_timeout) which makes the animation work unless the busy idle/timeout function is > G_PRIORITY_DEFAULT.
Created attachment 54737 [details] [review] Patch which fixes above issue Attached patch also adds an animation testcase to tests/testimage.c
Err, that should read "unless the busy idle/timeout function is < G_PRIORITY_DEFAULT" of course.
Why isn't the solution here to tell people not to install idle handlers with a higher priority than gdk redrawing?
That was just an example that can be replaced by any GSource with a priority of < GDK_PRIORITY_REDRAW, like a normal watch on an readable io channel that produces a lot of data. My point is that animations are evil unless they are used to show busyness ("I'm still alive, your app has not crashed") so they should be displayed reliably for the majority of use cases. Currently they just stop when the app is really busy. The patch improves this situation.
soeren, depending on who/what (libraries) set up the idle/timeout handlers, and on whether those have configurable prios (take a look at e.g. gnome canvas), changing the priority of other sources may be an option or not. ideally, adapting the prios in custom code is a possibility available, but some times it's not. in some cases there're good reasons to have idlers/timeouts which fight against redraw priorities, e.g. when doing realtime display of data, like a sample wave display. for the not so ideal cases, the attached patch does help, and it shouldn't hurt in the absense of differently prioritized handlers fighting over the CPU, so i think it should be applied.
I think we should apply the patch and possibly add a hint about problems with high-priority idles to the docs about GtkImage animation
Ok, will add an appropriate note to gtk_image_new_from_animation(). I guess it's fine to commit the testcase too?
Sure, testcases are great
Fixed in CVS: 2005-11-16 Michael Natterer <mitch@imendio.com> * gtk/gtkimage.c (animation_timeout): call gtk_window_process_updates() so the animation keeps running even if the main loop is busy with sources that eat a lot of cpu with high priority. Fixes bug #321444. (gtk_image_new_from_animation): document the fact that the animation will stop running if the main loop is busy with sources that have priorities higher than G_PRIORITY_DEFAULT. * tests/testimage.c: added test case that shows an animation even though a cpu-eating idle function is running.