xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: General Discussion: Performance
Date Mon, 08 Sep 2003 12:30:31 GMT
George Armhold wrote:
> 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.

   Do the elements overlap?

   If so the problem is most likely that we have to draw the previous
200 elements to put the last element on top - we don't try and optimize
a solid fill object being appended to the _very_ end of the document.

   If they don't overlap then I am a little suprised to see it slow down.
Also I think 1.5 had a reoccurance of a bug that caused all siblings to be
rerendered when an element was added to a group - this was fixed short
after in CVS so you might try that.

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




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


Mime
View raw message