Re: GtkImage animation performance

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

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?

  I think that the main point of queue_draw/expose is that, when the
widget is hidden or obscured by another window, the X server would not
generate an expose event, thus you don't spend time drawing something
that the user can't see anyway.

  But if queue_draw is consuming so much CPU, then there must be
something going on to cause this, and it should be fixed instead.

  Perhaps in a low-res/slow-cpu system without client/server
architecture queue_draw could be modified to do generate an expose event
immediately.  Unless it's the signal emission that is taking so much CPU
time...

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic