xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: [ batik-user ] : Batik Tunning and Performance Issues
Date Wed, 12 Jan 2005 13:50:52 GMT
Hi Jordi,

    Well you haven't really given us much information to go on.

Jordi Ferran wrote:

> I'm generating JPEG images with Batik for rendering a great amount of
> items, about 35.000 now. The problem is the speed, 8 to 50 seconds is
> unacceptable on the real-time scenario I must work with.

    What would be acceptable 6->48sec? 4->25sec? .8->5sec?
8-50millisec?  This will help us know if what you want is even
conceivable.

> Now I use the JPEGTranscoder class combine with a TranscoderInput. I
> manually build up the Document tree on memory and then give it to the
> TranscoderInput.

    Do you know where you are spending your time here?  How much is
your time building vs our time building/rendering?  Make sure you
are using our DOM Implementation so we don't have to copy it.

    Also as Tonny mentioned if you are restarting the JVM for each
rendering your performance will be abysmal, you must keep Java up
and running and submit jobs for rendering to it if you aren't already.

> My question is:
> Which tricky tunning optimizations can I do to speed up the rendering time ?

    Sure you just need to use the -goTenTimesFaster switch ;)

    Well what features of SVG are you using?  Is the content heavily
text/path/lines/images/primitive shapes?  Filters/masks?  How are
you styling the document?

    Is it a totally new 35K items or could you 'reuse' significant
parts of the document from render to render?

> I see different rendering times (8sec-50sec) depending on the
> resolution 400x300 faster than 2000x2000 pixel image, using the same
> amount of items to be rendered.

    Well the slowdown from 400x300->2kx2k seems excessive so I might
guess that you are running out of memory in the JVM.  You might look
at the Xmx option.

> It is any achievement using this library on a real-time scenario with
> a heavy load on the rendering component ?

    I don't know, no matter how fast or good a vector rendering engine
is you can _always_ provide content that takes "too long" to render.
So the answers to my first question are key to knowing the answer to
this question.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message