>>>>> "FI" == Felicia Ionascu <[EMAIL PROTECTED]> writes:
FI> I had a very unpleasant surprise when monitoring the memory
FI> consumption for a simple call on a TIFFTranscoder.transcode(..).
FI> The image is 992 x 1403 pixels and I was expecting at max
FI> allocated 5MB of RAM. What I got was about three times more: about
FI> 18MB!
FI> I searched in the sources, there are images created everywhere, in
FI> StaticRenderer, in ImageTranscoder...
Please remember, contributions are always welcome. Everyone has a
different itch to scratch.
FI> Not to mention what happens if we want to create a multipage TIFF
FI> afterwards, as all the pages are kept in memory before being
FI> written out.
If you are doing multi-page TIFF then what is kept in memory or
not as pages are written is really your issue not Batik's. You don't
have to generate full page buffers for each page ahead of time, you
can generate them on demand.
FI> There is no way of doing all this on the disk? It's very
FI> embarrasing if the amount of RAM is limited, and I don't think
FI> it's just the case of my application.
I don't think you want to do it on the disk, you just want to do
it in a demand pull fashion. The rendering engine of Batik supports
this fully, it's just the current implementation of transcoders that
expect to work with full page buffers.
I know this as I have generated 10kx20k Tiff images in the default
java partition, of course it takes writing some code, I haven't had
the time to generalize this and integrate it with the existing
transcoders but perhaps you would like to pick it up, polish it off
and contribute the result?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
