Hi Jeff,
Jeff Rafter wrote:
I have read quite a bit of the archives and bug database regarding SVGElementInstance-- I wanted to know what the current position on the discrepancy between the Batik implementation and the spec was. Is there any plan to correct this, is there a major hurdle to overcome?
I would not say there was a major hurdle to overcome. It just hasn't been a major issue to date.
I admit to having absolutely no idea about the architecture of Batik, but have spent a lot of time with SharpVectorGraphics on C# (including re-implementing this feature).
I have looked through the sources and (as near as I can tell), the functionality could be built out, at least partially, with relative ease. From last night's CVS, I think you could create and attach the an SVGElementInstance within SVGUseElementBridge.java line just after line 192. just after:
ue.setCSSImportedElementRoot(root);
This would provide the basic DOM interface. There would be a bit of an issue with changes because the current way Batik handles updates to a used subtree is to recreate the entire subtree. This would likely mess up the element instance tree mapping. This probably isn't a big deal for most cases but could cause some problems.
Essentially you would connect this created instance to the function getInstanceRoot() inside of the SVGOMUseElement. I assume that there is concern about two things: (1) memory leaks: There is a chance that (a) the created SVGElementInstance will need to be disposed. This can be handled when the <use> is disposed or the bridge node is recreated. (b) There is a chance that the dual references will hinder garbage collection (e.g. SVGElementInstance refers to both the use and localRefElement)-- I am not sure how to overcome this without knowing more about the architecture... any ideas?
So far GC shouldn't be an issue, as long as the ElementInstance tree is released in the dispose method of the SVGUseelementBridge. It's usually when you get to event listeners that you get memory leak issues...
(2) modifying the EventTarget apparatus for <use> and the referenced element to supply the SVGElementInstance as the target instead of the referenced node.
This is getting to the tricky bit. My intent was to kill two birds with one stone. I was going the have the ElementInstance (or a peer of it) be a 'special' Element that got all DOM attributes from the referenced element but used the 'use' element as the 'source' of it's CSS cascade. This 'special' element would then be the one associated with the GVT node. Thus when the 'real' node triggers a mutation event a matching event would be triggered on the 'special' element (I can think of several ways for this to happen, the cleanest would be to have one 'capture' event listener associated with the 'use' element on the used element's document root).
This would allow the use element to really track modifications and avoid the need to rebuild the entire subtree. It would also avoid the subtree clone nonsense, and fix the conformance issue.
The other factor is the need to support 'shadow' trees for sXBL. Which I think will need some of the same sorts of features although Cameron is the expert on this.
Additionally, browsing the code it seems that in cases where the referenced element is not a <symbol> and not an <svg> the referenced node is returned as is... should it not be wrapped in a <g>? It could be doing this and I am missing it...
Why do you think it needs a 'g' if the use element is referencing a single element I don't see the need.
Any help would be great-- I would even be willing to help implement this feature correctly if I had some admin/lead hand-holding :)
I'd be happy to help but to contribute this back you would need to have a CLA on file.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
