batik performances best practices

[David Delbecq <de...@meteo.be>]

Hello, 

we have developped a swing application that uses batik as it's main rendering interface, mainly because it was a vector based application. This application has an animation button, where, frame after frame, we change the content of the svg tree, mainly by raplacing a whole subtree. This basicaly look like this 

setCurrentFrame(int frame){ 
SVGElement newChild = getSVG(frame); 
element.replaceChild(oldChild,newChild); 
oldChild = newChild(); 
} 

called in a loop. The best we achieve is 12fps this way. If we remove the animated background, we go up to 19fps. It's simplified, the real operation are done using a Runnable added to the updatequeue of batik, so visual is up to date. 

My problem is that batik recalculates, for newChild, the GVT, which is obviously needed to display the SVG on the JSVGCanvas. Profiling operation show most of my time (~80%) is spent in GVT builder. Is there some way to tell batik to remember "newChild" so that, next time (next loop) i reinsert newChild, it doesn't need to rebuild the GVT tree but can reuse the previous one? 
Do you have any recommandation on how to handle animations with better performances? 

thanks for help 

David Delbecq 

Re: batik performances best practices

[Helder Magalhães <he...@gmail.com>]

Hi David,

I'd highly recommend using SMIL [1] to achieve those animated effects
(which should feel more intuitive and/or designer friendly) or, in
alternative, manipulate the DOM directly using Java [2] - faster - or
JavaScript [3]  - slower but with lots of utility libraries available.

Given your narrowed question I'm assuming you've already taken a good look
at the documentation, but I still didn't quite understand what does the
"animated background" stand for, as well as what the main animation looks
like. An example (maybe a small video recording, though a textual
explanation will also work) might help understanding what is the desired
goal and, so, receiving better feedback.

Cheers,
  Helder

[1] http://www.w3.org/TR/SVG11/animate.html
[2] http://xmlgraphics.apache.org/batik/using/scripting/java.html
[3] http://xmlgraphics.apache.org/batik/using/scripting/ecmascript.html
Em 10/03/2014 16:06, "David Delbecq" <de...@meteo.be> escreveu:

> Hello,
>
> we have developped a swing application that uses batik as it's main
> rendering interface, mainly because it was a vector based application. This
> application has an animation button, where, frame after frame, we change
> the content of the svg tree, mainly by raplacing a whole subtree. This
> basicaly look like this
>
> setCurrentFrame(int frame){
>     SVGElement newChild = getSVG(frame);
>     element.replaceChild(oldChild,newChild);
>     oldChild = newChild();
> }
>
> called in a loop. The best we achieve is 12fps this way. If we remove the
> animated background, we go up to 19fps. It's simplified, the real operation
> are done using a Runnable added to the updatequeue of batik, so visual is
> up to date.
>
> My problem is that batik recalculates, for newChild, the GVT, which is
> obviously needed to display the SVG on the JSVGCanvas. Profiling operation
> show most of my time (~80%) is spent in GVT builder. Is there some way to
> tell batik to remember "newChild" so that, next time (next loop) i reinsert
> newChild, it doesn't need to rebuild the GVT tree but can reuse the
> previous one?
> Do you have any recommandation on how to handle animations with better
> performances?
>
> thanks for help
>
> David Delbecq
>
>