nanogui: Thread: Nano-X: system load increases?

Hi all,

I'm using microwindows 0.89 with pcf fonts on a ppc embedded system with 
framebuffer. Everything is fine, but after a few hours (during this time 
my program uses the GrText() function to redraw some data) nano-X seems 
to get slower (the drawing of texts get slower). The freeram (I've used 
the sysinfo function to get this data) decreases, the system load 
increases.
Are there any lists or buffers in nano-X which are continously growing 
and which I can keep smaller?

Any suggestions?
Thanks a lot!

Klaus

@Greg:
@Jordan: The big endian patch works fine with pcf.gz files ( 
"HAVE_PCFGZ_SUPPORT       = Y") (on X86 & PPC platforms w/ Linux 2.4)

> I'm using microwindows 0.89 with pcf fonts on a ppc embedded system with 
> framebuffer. Everything is fine, but after a few hours (during this time 
> my program uses the GrText() function to redraw some data) nano-X seems 
> to get slower (the drawing of texts get slower). The freeram (I've used 
> the sysinfo function to get this data) decreases, the system load 
> increases.
> Are there any lists or buffers in nano-X which are continously growing 
> and which I can keep smaller?

Sounds like there's a memory leak.  I'll bet your
code opens the font with GrCreateFont and
then draws, then destroys the font?

It might be interesting to try the following, to help debug:

1. GrCreateFont using a built-in font, and see whether you
still have a memory leak.  If so, it's likely in your program.

2. Otherwise, we've likely got a leak in the pcf reader,
and the destroyfont function probably doesn't release
all the memory.  A quick review of engine/fonts_pcf.c
should determine this.

Regards,

Greg

>
>
>Sounds like there's a memory leak.  I'll bet your
>code opens the font with GrCreateFont and
>then draws, then destroys the font?
>
No, I create a Font with GrCreateFont on program start (I use a global 
var for this) and I use it all the time (I never destroy it).

>1. GrCreateFont using a built-in font, and see whether you
>still have a memory leak.  If so, it's likely in your program.
>
Ok, I'll test it anyway. Are there other caches or something which may 
grow during runtime (even during the first few hours?)?

Thanks and regards

Klaus

> Ok, I'll test it anyway. Are there other caches or something which may 
> grow during runtime (even during the first few hours?)?

No, text drawing itself doesn't allocate/free any memory.
Perhaps you should inspect your main loop and see
whether you allocate/free anything when you get an
expose event.  If the drawing gets slower per time,
perhaps you're allocating a clip region that's getting
more complex?

Regards,

Greg