Memory used with long use....

This is a screen shot of the memory usage just after killing it when it started to stall out and use my swap.
With a gig of ram I can go quite a while... but not too long with out filling my mem.

Have checked this out and confirmed it. I will look into this as a matter or urgency. This shouldn't be happening at all. I can't think off hand why it is happening. Thank you for this bug.

Looking today, I've not found out where the leak is coming from only, that it exists. Increasing the hang time and blend time makes the problem less relevant, in fact I managed to get the problem to be almost non-existent. I used pysizer to try to find the leak, but it's very difficult to see it. I can see a general trend of increase but can't pinpoint it at the moment. Will try again later.

Here is another picture.. I changed the settings to run blendtime and displaytime both at 1.
This sped up the error and we could see an interesting correlation between memory and run usage. Notice as the memory is climbing the processor spikes up and down erratically and the memory climbs at the same rate the whole time. (Mind you, most of my images are around the same size.) But here is the interesting part. Notice the drop for just a moment as the rise occurs? Weird huh? Wonder what that is. I will continue to play with settings to weed out the leak.

I believe what you are seeing is the loading of the next image. The
drop in memory, if that's where it is happening, my pocket pc won't
let me see the image, is probably due to the pix buffers being reset
in the textureloader class. The cpu spike is indicative of the image
resize operation. All images must be resized to, 512,512 or tilesize
if set, in order to display in opengl. But you have given me an idea
thanks.

--
Pete Savage - cbx33::silentk
wiki.ubuntu.com/PeteSavage

This is odd, I was running with silly figures for hangtime and blendtime, 10 and 10.

Notice the significant drop?

Check this out

This has been fixed now. Quoting from the pygtk FAQ

"Apparently finalizers are not necessarily called as soon as an object goes out of scope. My guess is that the python memory manager doesn't directly know about the storage allocated for the image buffer (since it's allocated by the gdk) and that it therefore doesn't know how fast memory is being consumed. The solution is to call gc.collect() at some appropriate place."

So I made a few changes to the way it runs and voila, memory bug solved ;)

Thanks Jason for pointing this one out. Nice that we caught it early on. I was beginning to think phimage was doomed.