Hello,
Thanks for the reply,
We're using Batik 1.5b4, but we'll move to the latest CVS version. Also, at
this stage, we're not using scripting.
Here's a basic SVG fragment, there can be up to 26 such ones per single file
:
<g id="PIP1">
<rect id="border" x="100" y="100" width="200" height="200"
style="fill:rgb(64,64,64); stroke:rgb(255,255,0);
stroke-width:1" rx="4" ry="4"/>
<g id="UMD" transform="translate(100 200)">
<rect id="label-rect" x="0" y="0" width="40" height="20"
style="fill:rgb(0,0,0)" rx="4" ry="4"/>
<text id="label-text" x="30" y="26"
style="fill:rgb(64,255,64);font-size:22;font-family:Arial">Miami</text>
</g>
</g>
Surely, we'll test different SVG variants of the above fragment to see if
performance is affected in any way, but are there any obvious ways to
optimize the fragment ? For example, it seems one way to optimize is to use
absolute positioning instead of relying on transform(). How about nested
groups ?
I was thinking about another approach as well. Is it possible to
custom-build an SVGDocument from the source SVG file and then set it into
JSVGCanvas ? What if I just SAX-parse the source and build SVGDocument on
the fly ? Would it make any difference in terms of performance ?
Cheers
Sergey Beryozkin
----- Original Message -----
From: "Thomas E Deweese" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Saturday, February 08, 2003 2:37 PM
Subject: RE: Question on JSVGCanvas/JSvgComponent
> >>>>> "SB" == Siarhei Biarozkin <[EMAIL PROTECTED]> writes:
>
> SB> Hello, We're using JSVGCanvas to show the SVG content in the
> SB> follwing way :
>
> SB> 1. Svg file is generated on the server 2. Our viewer, a subclass
> SB> of JSVGCanvas, calls JSVGDocument.loadSVGDocument(URL path to the
> SB> svg file)
>
> SB> It takes at least 5secs to draw that svg file (8K, it contains a
> SB> lot of group <g> blocks with basic elements like <rect> and <text>
> SB> inside).
>
> It sounds like a fairly small file, so I assume the 5secs is for
> the 'first time' display? Most of this time is Java loading classes
> and the JIT getting going, so there isn't much we can do about this.
> After the first time does it redraw much faster?
>
> SB> I'll certainly try to increase the size of JVM-heap at startup,
> SB> but apart from that, Is there any way on the application level to
> SB> accelerate the process ?
>
> Text is probably our biggest problem for performance. If you use
> lots of tspan's you might try to find ways to reduce them.
>
> SB> When the file is succesfully loaded and displayed, we start
> SB> manipulating some of the properties of the resulting SVGDocument
> SB> in the following way :
>
> SB> 1. SVGDocument svgDoc = JSVGDocument.getSVGDocument(); 2. Update
> SB> it as necessary 3. JSVGDocument.setSVGDocument(svgDoc) - as a
> SB> result the SVG view is updated.
>
> SB> The problem is that JSVGDocument.setSVGDocument() causes the whole
> SB> view redrawn, which takes few seconds.
>
> I'm guessing you are using Batik 1.1.1 (you don't say). If you
> switch to Batik 1.5b4 (or better current CVS) when you modify the
> document (which you must do in the update thread - search archives for
> examples) the display will automatically be updated (and only the
> regions that need to be).
>
> SB> If I call repaint(), it has no effect. Is there any way to cause
> SB> JSVGDocument to redraw only those parts of SVGDocument which have
> SB> really changed ? Again, apologies if these questions have already
> SB> been answered before.
>
> You might also have to tell JSVGDocument that it should treat the
> document as dynamic (also search the archives) - normally it tells
> this by checking if the document has a script element - if you do
> everything in Java it can't tell that it is going to be dynamic.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
