> Indeed this would be interesting for me too, my first application > that uses batik, puts ~700 simple graphic elements (rect, circle, > line) one after another into a Document rendered by a SVGCanvas via > the UpdateManager.RunnableQueue. In detail every 200ms one element > is added to the Queue to be processed...after ~200element the > processing and rendering of the SVGCanvas get jerky - say the > elements don't get renered one after another but in junks of 5 - 10 > elements at a time.
Our application animates SVG docs manually by manipulating the "visibility" attribute. We're doing dynamic updates to the DOM using the JSVGComponent. We found (using a profiler) that SVGDocument.getElementById was a bottleneck. Not surprising. A very effective speedup was to cache all the elements we care about in a HashMap when the doc is parsed. Thereafter we retrieve elements from the cache via XML id rather than getElementById. If you are repeatedly looking up elements by id then this approach might help you.
> Maybe priorize the RunnableQueue higher?
You might be able to tweak this on a platform-by-platform basis, but most of the Java guidelines recommend against this sort of approach to application tuning.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
