Re: GtkImage animation performance
- From: "Gustavo J. A. M. Carneiro" <gjc inescporto pt>
- To: "Komulainen Tommi (Nokia-M/Helsinki)" <tommi komulainen nokia com>
- Cc: gtk-devel-list gnome org
- Subject: Re: GtkImage animation performance
- Date: Sat, 02 Apr 2005 18:08:43 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]