xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thierry Kormann <tkorm...@sophia.inria.fr>
Subject Re: Transcoding pipeline and performance
Date Fri, 13 Apr 2001 17:18:25 GMT
On Wednesday 11 April 2001 14:36, Andreas Bielk wrote:

> 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