Reinhard Brandst�dter wrote:
Thomas DeWeese wrote:
I would take one of three routes here:
1) Don't load the document with setURI (do you even need to load
something from a URI?[*]), but load the document yourself, modify it and then
set it with setSVGDocument.
2) Move all your code into a Runnable and run it in the UpdateManager
Thread.
3) Load the document with setURI, then deep clone the Document, then
modify the clone (which doesn't have to be in the UpdateManager Thread and
the changes won't be tracked by the Canvas). Then you can set the
clone document on the canvas.
I think 2 is the best way to do it....but how would this perform if the
code in the Runnable is quite big? No issues on that?
So, if you 'construct' your new elements completely and then add them
to the tree the performance will be similar to building the tree
independent of the canvas. Where the 'live tracking' get's expensive
is when you change a large number of attributes/properties on an element
that is already in the rendered part of the DOM. For example changing
the x/y/w/h of a rectangle will cause the bounds, and fills and stroke
etc to be recomputed four times (once for each attribute).
When an element is not in the rendering tree it won't track this stuff.
So in the above example it may well be faster to remove the rect change
all the attribute and add the element back to the DOM.
I've tried something like 1 (isn't that quite similar to the code I
submitted in my original posting, except the setURI?)
Well yes, but this small difference is quite critical! By using setURI
the loaded document is automatically associated with the canvas - which
leads to the threading issues. By loading it yourself it isn't associate
until you call setSVGDocument.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
