Hello, Immediate update is working for me now. Before receiving your email, I tested our application with Batik built from the CVS checkout, and it didn't update, so I was just going to complain :-) again... Thanks for some insights into how the performance can be affected Cheers Sergey Beryozkin ----- Original Message ----- From: "Thomas E Deweese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Monday, February 10, 2003 12:33 PM Subject: Re: Question on JSVGCanvas/JSvgComponent
> >>>>> "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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
