xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Bielk" <andreas.bi...@codesense.com>
Subject RE: Transcoding pipeline and performance
Date Mon, 16 Apr 2001 10:35:58 GMT
Ok. I did some more profiling of my code, and building the GVT isn´t really
the hotspot I first thought it was. The time is mostly spent in:

StaticRenderer.repaint(Shape) ~ 40%
StaticRenderer.getOffScreen() ~ 25%
JPEGTranscoder.writeImage(BufferedImage, TranscoderOutput) ~ 17%
GVTBuilder.build(BridgeContext, Document) ~ 7%

So I don´t see any (big) performance gains from manipulating GVT anymore...

I´ll probably implement some schema to 'reuse' my SVGOMDocument objects
and pooling them between requests, so I don´t think the dynamic part of SVG
will help much.

/Andreas Bielk

> From: Thierry Kormann
> Sent: Friday, April 13, 2001 7:18 PM
> > 1. Parse template to SVGOMDocument
> > 2. Modifying the SVG DOM (adding/removing elements)
> > 3. Running transcoder with SVGDocument as TranscoderInput
> >
> > I need better performance for [2] and [3] ([1] is done at startup).
> Well, for your performance issue, I don't have any hint at this time. A
> possible solution will be to take advantage of the dynamic part
> of SVG (which
> is not implemented yet in Batik) and start rendering a DOM tree and then
> update it when needed.
> We are planning to do incremental update and you should have nice
> performance. We should start working on the dynamic part of SVG soon.
> > So I started to browse the Batik codebase to try and understand the
> > transcoding pipeline. I would like to do as much of the transcoding
> > as possible up-front, and add my elements at a lower level.
> >
> > As far as I can understand, this means manipulating the GVT Tree.
> This sounds a bit tricky at this time. GVT is one of our core
> module and is
> not really documented yet. Another disavantage of this solution
> is that you
> will have to learn our API instead of just dealing with a
> standard one such
> as the DOM.
> At last, I am not even sure that it's possible as our renderer is
> doing some
> cache and any modification to the GVT tree won't be taken into account.
> > What´s the best (or right) way to do this?
> Keep cool :)
> > Modifying the DOM and running some magic in the bridge?
> In a near future, you will just have to modify the DOM. All the
> updates will
> follow automatically.

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

View raw message