a really fast workaround would be to make a movie file out of your
images.
then just use [pix_film] instead of [pix_multiimage].
control [pix_film] by giving it the frame number to display.
max
Am 16.03.2007 um 02:44 schrieb orjo:
i am currently working on a gem-project that uses a lot of images. the images are loaded and switched with [pix_multiimage] - and i
want to change the set of images a few times, so i load quite a lot of images into memory..and quite soon - after having loaded a few sets - all together about 2 or 3 thousand pictures, the "too many open files" message occurs.
is there some fix or workaround for gem on win32 yet ? my project is nearly done - so this is the only (and a quite serious) problem i got. would need something like a really fast fix or workaround ;)
the bug should be already known, cause i found this old mailing list posting by someone that apparently had problems with the same bug:
"[GEM-dev] fixed filehandle leak? *Mathieu Bouchard* matju at artengine.ca <mailto:gem-dev%40iem.at?Subject=%5BGEM-dev%5D%20fixed%20filehandle% 20leak%3F&In-Reply-To=> /Mon Jun 13 23:04:02 CEST 2005/
Here's a bug that causes a filehandle leak in GEM. Every time an image load is attempted via image2mem() (used by [pix_image], [pix_multiimage], etc.) then a series of decoders are called one after the other, quitting after the first that succeeds. If the file exists and is not of any type handled before the SGI handler and not of SGI type either, the SGI decoder does not close the file handle.
This happened several times when loading a *lot* of TIFF images on Windows during a Pd/GEM workshop at Videographe, this afternoon. When too many files are "open", then PureData can't open any new patch and can't even save any modified patches!"
any help appreciated.
thanks,
lorenz
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list