Re: Optimization question

["Robert G. Werner" <rwerner mail microbsys com>]

I'm not familiar enough with the GTK drawing routines to speak to
specifics but I'll make a couple of suggestions from what I do know.

1.  It seems like most GTK routines are set up to deal with xpm
formated images and everything else must be converted to and from
them.  If you can,  use Gimp or something to convert your images to
xpm files and use them directly,  that will get rid of your converting
needs (not sure if xpm deals with transparency but it seems like it
should).

2.  Rather than drawing and destroying your numbers each time you want
to change them,  could you create an array and just loop through them,
drawing and then hiding them?  I'm not sure how this would be done but
it seems like this should be an obvious optimization.

-- 
Robert G. Werner
rwerner mail microbsys com
2001/9/11

You've been leading a dog's life.  Stay off the furniture.

On Mon, 4 Feb 2002, Daniel Carrera wrote:

> Hello,
> I'm working on a space station simulation and I need some optimization
> advice.  The bottleneck is definitely the altitude reading.  It consists
> of a 6-digit number that is rendered to the screen using images (PNGs).
> To create the feeling of real time, this number is updated every 10
> milliseconds.
>
> I definitely want to use images for the simulation.  It is intended for
> preschoolers so it should look nice.
>
> I have a few questions:
> 1)  Is there any particular format that is rendered faster than the
> others?  I am using PNGs right now.  Should I use something else?
>
> 2)  How does Gtk manage memory?  If one object is hidden by another, is
> the first still in memory?  I ask because currently the altitude reading
> belongs to a canvas group.  Every time that the altitude is updated (every
> 10 milliseconds) I destroy the group and build an entirely new one.
>
>     This must consume a lot of CPU power.  I thought that I might just
> draw the new number on top each time.  However, if the old ones will
> remain in memory, this approach would suck the entire system's memory very
> quickly.
>
>
> Any advice on this matter would be much appreciated.
>
> Thanks in advance,
> Daniel.
>
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list