Re: PNGTranscoder: reuse, multithreading

[th...@kodak.com]

Hi Joe,

news <ne...@ger.gmane.org> wrote on 11/13/2007 08:37:38 AM:

> I have different threads working on the same document
> and simultaneously requesting a png file for a
> specific area of interest.

   This is illegal.  A Document is single threaded.

> The first approach instantiated a PNGTranscoder instance for every 
thread.
> This is a problematic approach because of high memory usage for
> preparing the PNGTranscoder instance.
> I am aware of that, but what I do not understand is why I get
> strange exceptions that hint a multithreading issue deep down
> under the hood of the ImageTranscoder.
> This seems to be related to the Batik CSS engine and looks like so:

   This is because each transcoder is trying to attach a CSS engine
to the document simultaneously.

> Does anybody have an explanation for this behavior?
> 
> An alternative approach would be to reuse the PNGTranscoder
> instance (after setting it up for a specific document)
> 
> The thing is I do not know if ImageTranscoder instances are prepared
> for this and I guess the odds for making one PNGTranscoder instance
> work with multiple threads w/o synchronizing don't look good given
> the exception above.

   I'm not certain you can use the Transcoder as is.  However you
should be able to build one GVT for the document and perform multiple
renderings on that at one time (I think...).  As long as you are
not manipulating the document in any way, just rendering different
areas.

> I guess the big question here is how to integrate an ImageTranscoder
> instance(s) into a servlet environment in order to achieve
> maximum troughput for image generation for the same/different
> document(s). 

   Build the Graphics Tree (GVT) once for the document then render
that multiple times.  This will be much faster and save lots of 
memory.  If there might be lots of overlap between the regions
rendered by each thread you might use one of the caching renderers
which is attached to an LRU cache of tiles.

> Eventually I would like to have a couple of threads generate an image 
for
> document A and another thread group generate images for document B all
> concurrently with minumum memory overhead and execution speeds.

   Hope this helps.