On Friday 07 May 2010 19:08:49 Fabien Bodard wrote: > frame = frame.Stretch(NewWidth, NewHeight) > > if you do not re assign frame stretching returned image ... the image > will not be changed > > http://gambasdoc.org/help/comp/gb.image.imlib/image/stretch?v3 > > 2010/5/7 Richard <[email protected]>: > > Hi everybody, > > > > I am using Gambas 2.20.0 on Mandriva 2010.0. The desktop is LXDE and the > > gui toolkit might possibly be GTK. > > > > I have written a button event handler to process hundreds or thousands of > > .png images in a directory. The main memory available when the program > > starts is around 1.8 GBytes. After processing just 744 images (in > > testing) this falls to about 74 MBytes. The memory is not freed on exit > > from the event handler, only when I exit from the program. > > > > I use only 1 Image object; a variable called "frame". I have tried > > declaring this as a local in the event handler and as a class-visible > > variable with no apparent change in the way memory is eaten and never > > disgorged. > > > > I do three things with my frame variable in a loop which iterates for all > > frames in a directory; > > > > 1. I load it from an image on disc > > 2. I "stretch" it to make its width smaller(!) > > 3. I save the altered frame to a different directory > > > > Specifically the significant lines of code look like; > > > > frame = Image.Load(SourceImage) > > frame.Stretch(NewWidth, NewHeight) > > frame.Save(DestinationImage) > > > > Outside the loop I now do frame = NULL, but this has no effect. > > > > Is it possible that my code is allocating multiple "anonymous" frame > > objects and not releasing them? I have read Benoit's explanation in this > > list of Gambas memory management (Re: [Gambas-user] Memory Management, on > > 08/09/2007 09:19). > > > > I turned to Gambas to program this function because my first choice, > > imagemagick, would always run out of memory without processing a single > > frame. The Gambas solution works, but no more work can be done without > > killing the program and restarting it - not very convenient. I anticipate > > that typical uses of the program will have to handle 10-30 thousand png > > images at a time. > > > > Can anyone suggest how I find out what is so hungry for my memory, and > > hopefully how to suppress its appetite? > > > > Richard > > > > ------------------------------------------------------------------------- > >----- > > > > _______________________________________________ > > Gambas-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/gambas-user > > --------------------------------------------------------------------------- >--- > > _______________________________________________ > Gambas-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/gambas-user
Thanks for reminding me, Fabien, about a fascinating side issue. Originally I had tried frame.Resize(NewWidth, NewHeight) but I was disappointed to discover it doesn't resize the image at all; it just re-frames it by cropping the right hand side. I changed to Stretch by just typing over Resize and was quite a bit surprised when that didn't seem to work either! That was when I realised that while Resize(W,H) is a procedure, Stretch(W,H) is, as you said, a function! I was a bit hasty in providing my example code lines so I repeated the mistake which I had corrected in my event handler and which you have corrected above. The code which I copied for my example does not assign the result of the Stretch function, but immediately writes it back to disc. It reads: frame.Stretch(NewWidth,NewHeight).Save(DestinationImage) It works. This is what I do now, although I had originally used the version you suggested and assigned the "stretched" image to my frame variable before saving. I have been trying to nail down the greedy memory culprit and the frame.Stretch().Save() version made no difference, but I was too lazy to change it back to frame=frame.Stretch() followed by frame.Save(). I have since discovered that it is the frame=Image.Load() step which is to blame. Each png is at most 1MiB, though most are much less. 740 of these when loaded in turn by frame=Image.Load() uses 1.8GiB of main memory and nearly 2GiB of swap. This seems excessive to me, especially since I don't seem able to get it back without quitting from the program. Any ideas about that? Richard ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
