GNOME Bugzilla – Bug 445626
Window rendering is sluggish when using lots of animated images
Last modified: 2018-02-10 03:45:27 UTC
Hi, A while ago I reported a case where the use of animated images in a GTK application causes a slowdown ( http://bugzilla.gnome.org/show_bug.cgi?id=427660 ). While the fix for that case improved the performance a lot, there still is room for more improvement. In a GTK application I wrote a GtkWindow is created which contains a textview, some normal buttons and around 8 buttons with animated images in them. I've had several reports of users of my program that this window is taking lots of CPU time and isn't very responsive. When I tried to reproduce the problem on my local box I also encountered this slowdown and I tried to create a seperate testcase to illustrate the bad responsive behaviour. In this testcase I created a 10x10 table in which each cell contains an animated image. As you can see the rendering of the animated images is taking quite some CPU time and the animation itself is very sluggish.
Created attachment 89626 [details] testcase to show the described behaviour
Created attachment 89627 [details] animated image I used
The reason is that GtkImage calls gdk_window_process_updates() which calls displayIfNeeded on the view. If this is done too frequently, quartz blocks all other drawing until the next vsync so we need to throttle the updating a bit... I have a patch that fixes the problem but it might have bad side effects so I will test it a bit more (and clean up it).
Created attachment 92818 [details] [review] Throttles flushing Could you please try this patch and also run any other test cases you have to see if it breaks anything? I have tried gimp and gossip and gtk-demo.
(My suspicion is that it will make things draw too little sometimes)
Thanks for your patch. Apart from testing this myself I'm also going to ask some users of my program if they want to test this and ask if they are noticing any oddities.
Thanks! I have a new patch that takes care of the missed redraws that happened sometimes with the first attempt.
Created attachment 92874 [details] [review] New attempt
Okey, gonna try out with your new patch
No one of my users has reported any problems with your patch. Just that the performance has improved :D
Thanks :) I will try to finish the patch and get it included. It still needs a bit of cleaning up.
How come this patch isn't in SVN yet?
There were some problems introduced by it, and it's not clear yet how to solve them.
gdk_window_process_updates() is extremely similar to displayIfNeeded() in intent and behavior, and adding a layer to try and shield quartz against application misbehavior strikes me as pretty ugly. I would suggest that the patch to GtkImage from bug 321444 (r14267) is just wrong and should be reverted. As a goal, we should be moving to a model where we draw everything that needs to be drawn toplevel in a "frame"; if quartz wants to throttle that framerate to the vblank, that's a good thing, not a bad thing.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.