>>>>> "SB" == Siarhei Biarozkin <[EMAIL PROTECTED]> writes:
SB> Thanks for the reply, We're using Batik 1.5b4, but we'll
SB> move to the latest CVS version. Also, at this stage, we're not
SB> using scripting.
Then the reason your rendering doesn't immediately update is
because Batik thinks it's a static rendering. You will need to tell
the JSVGCanvas to always treat the document as dynamic.
SB> Here's a basic SVG fragment, there can be up to 26 such ones per
SB> single file :
Well you didn't answer any of my other questions (first time vs
following times). In my experience 26 text elements shouldn't be very
slow (this get's to be signficant for 100's of text elements - or
tspans).
Unfortunately, the last time I checked largest time hits are the
JDK classes that we use to do BIDI and text annotation - this makes it
difficult to optimize. Also the first time through loading the fonts
takes quite a while.
That all said I think the bottle neck here is the loading of the
Batik classes which we have no control over.
SB> Surely, we'll test different SVG variants of the above fragment to
SB> see if performance is affected in any way, but are there any
SB> obvious ways to optimize the fragment ? For example, it seems one
SB> way to optimize is to use absolute positioning instead of relying
SB> on transform(). How about nested groups ?
In my experience none of these have significant impact, the
biggest thing you can do is to try to avoid using multiple tspans -
which you are already doing.
SB> I was thinking about another approach as well. Is it possible to
SB> custom-build an SVGDocument from the source SVG file and then set
SB> it into JSVGCanvas ? What if I just SAX-parse the source and build
SB> SVGDocument on the fly ? Would it make any difference in terms of
SB> performance ?
When you set the URL on the JSVGCanvas the JSVGCanvas just parses
the document so I'm not sure why you doing the parsing would be any
quicker... The only cases where this might be true is if the svg is
embedded in a larger document or something odd like that.
SB> Cheers Sergey Beryozkin ----- Original Message ----- From: "Thomas
SB> E Deweese" <[EMAIL PROTECTED]> To: "Batik Users"
SB> <[EMAIL PROTECTED]> Sent: Saturday, February 08, 2003
SB> 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]
>>
>>
>>
SB> ---------------------------------------------------------------------
SB> To unsubscribe, e-mail: [EMAIL PROTECTED] For
SB> additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
