Jeff Rafter wrote:
>> BTW I don't think you would see a significant improvement in
>>the performance by using these methods, Batik does wait until
>>the script ends before updating the display.
>
> No it doesn't. At least not in all cases. For example try:
>
> http://jeffrafter.com/SVG/tests/zoom.svg
> Click on the red box. In ASV nothing happens between the two alerts, but
> in squiggle you see a rerender. Maybe there is a special case for
> popups?
I just did, I don't get a rerender between the two (with either
1.5.1 or the current CVS releases). I will mention that the example
does use a feature who's implementation is a little funky which is
the currentScale (or translate) for that matter. The funkiness comes
because that feature is "shared" between SVG and the AWT display
engine.
> I know that when Ksvg2 implemented JS update caching the tests
> showed a pretty dramatic improvement.
Well, yes redrawing the canvas after every DOM manipulation
is quite expensive. I will mention that Batik is not totally
lazy about DOM manipulations so Batik will update it's rendering
tree as modifications are made to the DOM which in cases that involve
large number of changes to individual elements can get expensive.
But simply turning off renderings wouldn't effect this. I don't think
this is the problem with the example given, I think it just takes a
while for Java2D to render.
In test_render it appears to take ~2ms for the DOM updates. The
rest is rendering time.
-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
