You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Ralf Siegel <ra...@audiofarm.de> on 2003/09/07 14:24:34 UTC
General Discussion: Performance
I know this sounds like quite a generic question, but I would be interested
to actually hear what people have found out to be essential in order to
increase rendering speed with using both Batik's Image Transcoder + the
Canvas component.
Currently I'm rendering about 200 UI graphics (ARGB images) prior to
application start which takes about 1:30 minutes, i.e. I'm looking for
bottlenecks since the number of graphics will heavily grow in the future :o)
ralf ...
-------------------------------------------------------------
Ralf Siegel - Freelance Developer
Recommended Listening: Broadcast - Haha Sound (Warp)
contact_site: mailto:ralf@audiofarm.de
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Ralf Siegel <ra...@audiofarm.de>.
> Depending on how large the layer changes are you might do well to
>use the 'Dynamic Renderer' that will only rerender the changed areas.
Thanks again for the tipp, I will definitely look into that!
>I am almost certain that by default A & B will each load and parse
>'elements.svg' once - not twice.
Yep exactly, that's what I mean - A & B will *each* load and parse
"elements.svg" once, which means it's being loaded and parsed twice ...
> I believe all this caching behaviour is controlled by the 'DocumentLoader'
>class in the batik.bridge package. This is normally constructed fresh for
>each document by the BridgeContext - however you can construct one 'up front'
>and pass it to the BridgeContext's contstructor - so it can reuse documents.
Ah, okay - I will stick my head into that area.
Thanks Thomas.
ralf ...
-------------------------------------------------------------
Ralf Siegel - Freelance Developer
Recommended Listening: Broadcast - Haha Sound (Warp)
contact_site: mailto:ralf@audiofarm.de
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Thomas DeWeese <Th...@Kodak.com>.
Ralf Siegel wrote:
>
>> One possible solution would be to merge all the graphics into
>> one larger graphic (one document with say 200 image elements or
>> better just put them all in one document). Then you can pull the
>> results out of the generated image. You might also consider
>> stratagies where you only do this once and cache the generated
>> graphics on the client.
>
>
> Cool - it seems like I'm on the right track :o) I already have a SVG
> Loader implemented which caches parsed documents and e.g. renders
> multiple buttons by switching layers + the generated graphics are saved
> to disc for a fast startup.
Depending on how large the layer changes are you might do well to
use the 'Dynamic Renderer' that will only rerender the changed areas.
> What about that case: Assuming there is an SVG document 'elements.svg'
> which holds three elements 'green', 'blue', 'red'. Then there are
> anpther two separate SVG files which are referencing certain elements in
> that document, i.e.
>
> ---> "A.svg" uses element 'green' and 'red'
>
> ---> "B.svg" uses elememt 'blue' and 'red'
>
> Question: Both "A.svg" and "B.svg" require AFAIK to load and parse
> "elements.svg" twice, right? Could you simply tell Batik to keep
> "elements.svg" for later reuse?
I am almost certain that by default A & B will each load and parse
'elements.svg' once - not twice.
I believe all this caching behaviour is controlled by the 'DocumentLoader'
class in the batik.bridge package. This is normally constructed fresh for
each document by the BridgeContext - however you can construct one 'up front'
and pass it to the BridgeContext's contstructor - so it can reuse documents.
>
> ralf ...
>
>
> ------------------------------------------------------------
> Ralf Siegel - Freelance Developer
> Recommended Listening: Broadcast - Haha Sound (Warp)
> contact_site: mailto:ralf@audiofarm.de
> -------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> 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
Re: General Discussion: Performance
Posted by Ralf Siegel <ra...@audiofarm.de>.
> One possible solution would be to merge all the graphics into
>one larger graphic (one document with say 200 image elements or
>better just put them all in one document). Then you can pull the
>results out of the generated image. You might also consider
>stratagies where you only do this once and cache the generated
>graphics on the client.
Cool - it seems like I'm on the right track :o) I already have a SVG Loader
implemented which caches parsed documents and e.g. renders multiple buttons
by switching layers + the generated graphics are saved to disc for a fast
startup.
What about that case: Assuming there is an SVG document 'elements.svg'
which holds three elements 'green', 'blue', 'red'. Then there are anpther
two separate SVG files which are referencing certain elements in that
document, i.e.
---> "A.svg" uses element 'green' and 'red'
---> "B.svg" uses elememt 'blue' and 'red'
Question: Both "A.svg" and "B.svg" require AFAIK to load and parse
"elements.svg" twice, right? Could you simply tell Batik to keep
"elements.svg" for later reuse?
ralf ...
------------------------------------------------------------
Ralf Siegel - Freelance Developer
Recommended Listening: Broadcast - Haha Sound (Warp)
contact_site: mailto:ralf@audiofarm.de
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Reinhard Brandstädter <r....@gmx.at>.
Thomas DeWeese wrote:
> It sounds like you are getting the bug from 1.5. It sounds like
> the amount of rendering required from element 20 on up should be
> constant. However if they are all children of the SVG element
> the bug will cause all of them to rendered (rather than just the
> 20 or so that intersect the area under the new element).
>
> You should definately try updating to current CVS.
I'll do so. Thanks for the hint.
Reinhard
--
Reinhard Brandstaedter r.brandstaedter@gmx.at GPG: 0x033B81DB
- Student of Computer Science - J.K. University of Linz -
- <ICQ: 73059068> <Mobile: +43 699 12419541> -
- http://adelaide.dnsalias.net -
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Thomas DeWeese <Th...@Kodak.com>.
Reinhard Brandstädter wrote:
> Thomas DeWeese wrote:
>
>> 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.
>
>
> Well, yes alway the last 20 elements or so do overlap.
> The document structure is fairly flat, most of the elements are direct
> childs of the svg element itself.
It sounds like you are getting the bug from 1.5. It sounds like
the amount of rendering required from element 20 on up should be
constant. However if they are all children of the SVG element
the bug will cause all of them to rendered (rather than just the
20 or so that intersect the area under the new element).
You should definately try updating to current CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Reinhard Brandstädter <r....@gmx.at>.
Thomas DeWeese wrote:
> 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.
Well, yes alway the last 20 elements or so do overlap.
The document structure is fairly flat, most of the elements are direct
childs of the svg element itself.
Reinhard
--
Reinhard Brandstaedter r.brandstaedter@gmx.at GPG: 0x033B81DB
- Student of Computer Science - J.K. University of Linz -
- <ICQ: 73059068> <Mobile: +43 699 12419541> -
- http://adelaide.dnsalias.net -
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Thomas DeWeese <Th...@Kodak.com>.
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
Re: General Discussion: Performance
Posted by George Armhold <ar...@cs.rutgers.edu>.
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
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
Re: General Discussion: Performance
Posted by Thomas DeWeese <Th...@Kodak.com>.
Reinhard Brandstädter wrote:
> Ralf Siegel wrote:
>
>> I know this sounds like quite a generic question, but I would be
>> interested to actually hear what people have found out to be essential
>> in order to increase rendering speed with using both Batik's Image
>> Transcoder + the Canvas component.
>>
>> Currently I'm rendering about 200 UI graphics (ARGB images) prior to
>> application start which takes about 1:30 minutes, i.e. I'm looking for
>> bottlenecks since the number of graphics will heavily grow in the
>> future :o)
One possible solution would be to merge all the graphics into
one larger graphic (one document with say 200 image elements or
better just put them all in one document). Then you can pull the
results out of the generated image. You might also consider
stratagies where you only do this once and cache the generated
graphics on the client.
> 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.
>
> Maybe priorize the RunnableQueue higher? I don't think so, I think the
> performance problem is inherent with the processing of a DOM tree.
>
> cheers,
> Reinhard
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: General Discussion: Performance
Posted by Reinhard Brandstädter <r....@gmx.at>.
Ralf Siegel wrote:
> I know this sounds like quite a generic question, but I would be
> interested to actually hear what people have found out to be essential
> in order to increase rendering speed with using both Batik's Image
> Transcoder + the Canvas component.
>
> Currently I'm rendering about 200 UI graphics (ARGB images) prior to
> application start which takes about 1:30 minutes, i.e. I'm looking for
> bottlenecks since the number of graphics will heavily grow in the future
> :o)
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.
Maybe priorize the RunnableQueue higher? I don't think so, I think the
performance problem is inherent with the processing of a DOM tree.
cheers,
Reinhard
--
Reinhard Brandstaedter r.brandstaedter@gmx.at GPG: 0x033B81DB
- Student of Computer Science - J.K. University of Linz -
- <ICQ: 73059068> <Mobile: +43 699 12419541> -
- http://adelaide.dnsalias.net -
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org