xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Armhold <armh...@cs.rutgers.edu>
Subject Re: General Discussion: Performance
Date Mon, 08 Sep 2003 07:49:29 GMT
Reinhard Brandst├Ądter wrote:

 > 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

 > 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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message