resource management...
Good Day, While I've messed around with the gimp for a few years, now that I have a digital camera, I'm getting started with gimp programming. FYI, I'm a seasoned programmer, so I won't post any general programming questions... First off I think the gimp's architecture is totally cool, as it is more an image manipulation framework than an application. I'm also in the camp of those who actually think scheme is a cool extension language, and would rather see the few problems ironed out there rather than moving to something like perl, but that's IMHO. I know a lot of people aren't down with functional programming languages. Ok now my questions. I am correct in saying that memory management of gimp resources is an issue for script programmers? For instance if I load an image, I assume I must do one of the following to prevent a memory leak: 1) display it so the user can manage it. 2) destroy it with gimp-image-delete 3) provide a UI to the user which allows them to manage undisplayed resources. More generally is it possible for script-fu scripts to introduce memory leaks even tough scheme in itself is a garbage collected language? Secondly, I'm confused by the function gimp-file-save. Specifically why do I need to pass an image and a drawable? If I load an image, do some image level manipulations on it, and then want to save it with gimp-image-save, do I need to create a layer? ~christopher == christopher bausCome down off the cross, waiting for snowwe could use the wood. in Tahoe, NV-- Tom Waits.
Re: resource management...
On Thu, Aug 24, 2000 at 03:06:10PM -0700, christopher baus [EMAIL PROTECTED] wrote: something like perl, but that's IMHO. I know a lot of people aren't down with functional programming languages. (... like perl ;) Anyway, it seems nobody has the time and energy to really work on the needed changes in script-fu to make it a viable programming environment. More generally is it possible for script-fu scripts to introduce memory leaks even tough scheme in itself is a garbage collected language? In script-fu it shouldn't be possible to enerate memory leaks, but a plug-in (like script-fu) can easily create memory lekas within the main gimp application. This is not easy to solve, and the question is wether it should be "solved" for all cases (I can think of a lot of cases where holding images inside the gimp for cahcing reasions makes a lot of sense, without them being actively referenced). I need to pass an image and a drawable? If I load an image, do some image level manipulations on it, and then want to save it with gimp-image-save, do I need to create a layer? If your image doesn not already have a layer you have nothing to save, so just use the existing layer. If you are sure your save plug-in does not depend on the layer (most don't) you can also pass in -1 or gimp_image_layer_active (or whatever its called). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: resource management...
On Thu, Aug 24, 2000 at 03:06:10PM -0700, christopher baus wrote: Secondly, I'm confused by the function gimp-file-save. Specifically why do I need to pass an image and a drawable? If I load an image, do some image level manipulations on it, and then want to save it with gimp-image-save, do I need to create a layer? Short answer: All images have at least one layer (the background layer, by default). Long answer: All plug-in procedures are required to take both an image and a drawable. In practice, one or the other of the arguments is usually ignored. Blah blah history, blah sucks bla, blah blah will do better in version 2.0.
Re: resource management...
On Fri, 25 Aug 2000, Marc Lehmann wrote: More generally is it possible for script-fu scripts to introduce memory leaks even tough scheme in itself is a garbage collected language? I think that if a script terminates unexpectedly it leaks all GIMP resources that it created. If the resource, such as a image, has been displayed then the user can manually clean these up, but for invisible resources (which include all images if you're using net-fu) are leaked. it should be "solved" for all cases (I can think of a lot of cases where holding images inside the gimp for cahcing reasions makes a lot of sense, without them being actively referenced). Sure, but it isn't unreasonable to expect script writers to call a function to tell GIMP that this object (image) should be preserved after teh script terminates. That way, anything which hasn't been explicitely flagged in this manner could be garbage collected after the script terminates. While it may not be possible/feasible/worthwhile having GIMP "garbage collect" every possible resource after a script terminates, it should be fairly easy to reap the worst offenders (images?). -Dave http://www.flamingtext.com/
Re: resource management...
Hi, Secondly, I'm confused by the function gimp-file-save. Specifically why do I need to pass an image and a drawable? If I load an image, do some image level manipulations on it, and then want to save it with gimp-image-save, do I need to create a layer? most save plug-ins can not handle multiple layers and will therefore only save the drawable you pass them and silently ignore the rest of the image (and the image_ID). Other plug-ins (gif for example) do something useful with all layers (creating an animation in this example) and ignore the drawable_ID. Salut, Sven
Re: resource management...
Anyway, it seems nobody has the time and energy to really work on the needed changes in script-fu to make it a viable programming environment. More generally is it possible for script-fu scripts to introduce memory leaks even tough scheme in itself is a garbage collected language? In script-fu it shouldn't be possible to enerate memory leaks, but a plug-in (like script-fu) can easily create memory lekas within the main gimp application. This is not easy to solve, and the question is wether it should be "solved" for all cases (I can think of a lot of cases where holding images inside the gimp for cahcing reasions makes a lot of sense, without them being actively referenced). I think it is reasonable that plugins/scripts can create resources that are outside the scope of the plugin/script itself. The developer just needs to be aware that's what is happening. Ok so now I'm aware of it. Cool. Its somewhat of an interesting issue. == christopher bausCome down off the cross, waiting for snowwe could use the wood. in Tahoe, NV-- Tom Waits.