Re: GtkImage animation performance

[Havoc Pennington <hp redhat com>]

On Wed, 2005-03-30 at 19:37 +0300, Komulainen Tommi (Nokia-M/Helsinki)
wrote:
> Hi,
> 
> When GtkImage needs to draw the next frame in animation it calls
> gtk_widget_queue_draw() and does the actual drawing whenever.  Now with
> slower hardware this simple queuing is causing quite a significant
> performance hit.  Displaying a 24x24 10fps animation with GtkImage makes
> some 20% CPU load; if you manually handle timeouts and gdk_draw_pixbuf()
> the load is closer to 5% using the same animation.
> 
> I was wondering if there were some good reasons for animations to go
> through the whole redraw queuing all the time?  Couldn't the next frame
> be drawn directly instead?
> 
> When all you really need to update is the animation frame it would be
> quite more efficient to simply draw the new frame directly.  And I think
> the same would apply to progress bars as well.
> 

I'm not convinced we understand the 5% vs. 20% difference; there's no
reason I know of that queuing the draw should be that much more
inefficient. If it is, we should really understand why it's so much
slower and address the problem globally.

Maybe you can use something like sysprof or oprofile and capture some
data on what causes the slowdown?

Havoc