Jorg Heymans wrote:
Thomas DeWeese wrote:
Jorg Heymans wrote:
What happens if you add this at the start of your sample document:
It appears almost instantly in squiggle, so actually rendering does not
seem to be the problem.
This example does just what you are doing, it takes the
'g' and uses appendChild to add it to the rendered part of the
DOM tree.
i'm really only doing
//this takes few milliseconds
Node importednode = mydoc.importNode(retrievedNodes,true);
//this takes ages
orginalNode.getParentNode().replaceChild(importednode,originalnode);
Well I've got to guess that there is something funny
in your setup. You can start adding logging to try and
track down what is really taking the time but since this
is pretty quick in Squiggle it isn't likely the Batik Core.
What is the child you are replacing?
Do you have DOM event listeners registered on the document
that might do time consuming things?
//after this the update manager kicks for rendering i guess, that also
only takes about 750ms
Can namespaces be an issue? The node i am trying to import comes from a
document with foreign namespaces, just guessing .....
No namespaces are not likely to be the issue. They would be
sorted out during the import anyway.
You might want to look at the code in parseXML in
bridge.ScriptingEnvironment (or you might just want to call that
yourself).
I'll have a look at this thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
