[Gegl-developer] memory handling as a lib [was: Re: tile size in filters]

[Dierk Fröhling]

Dierk Fröhling wrote:
> 
> Hans Petter Jansson wrote:
>> On Thu, 2008-10-09 at 11:08 +0200, Dierk Fröhling wrote:
>>
>>> I need to handle all pixels of an image in one tile for my new filter.
>>> The problem is that every pixel in the filtered image should depend on
>>> values from all other pixels...
>>> I tried out different things from other (example) filters (including the
>>> bounding box stuff) but my image is always split into several tiles.
>>> Is there any way to tell the gegl infrastructure to use the whole image
>>> as one tile as input pad?
>>> The bounding box stuff doesn't work especially because the size of
>>> images can differ.
>>> I know that this could lead to memory problems with really big images...
>> I wrote a color reduction filter that does Floyd-Steinberg dithering,
>> where each pixel depends on all previous pixels (the bottom-right pixel
>> depends on the entire image). It should be among the workshop filters.
>> Maybe that'd be useful to look at.
> 
> This worked up to a certain size of images - but with an image with 3112
> x 4200 pixels I get this message from gegl:
> 
> ** Message: unable to write tile data to self: No space left on device
> (-1/131072 bytes written)
> 
> There is enough space in my /tmp directory and all other possible
> working directories for gegl - 2GB of memory should be enough as well...
> It's not that my filter won't work at all with these big images - but
> only in parts. It seems that gegl splits it into tiles again...

Ok - I found out myself about the "no space left on device" - changing
the value of environment variable GEGL_SWAP to another filesystem which
has not only 500MB but 1GB free fixed this.
But this works only if I call gegl as a standalone application.
If I call it as a library from within my own application it seems to
ignore environment variables and uses RAM swapping again with this 256MB
limit which is to less for my images...
Does anybody know a solution? Or is this a bug in the gegl-lib?

Dierk