You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Jeff Rafter <li...@jeffrafter.com> on 2005/04/11 05:05:54 UTC
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 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);
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? (2) modifying the EventTarget
apparatus for <use> and the referenced element to supply the
SVGElementInstance as the target instead of the referenced node.
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...
Any help would be great-- I would even be willing to help implement this
feature correctly if I had some admin/lead hand-holding :)
Thanks,
Jeff Rafter
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re:
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jeff,
Jeff Rafter wrote:
>> 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 sounds excellent. A low-end solution would be to simply handle the
> four mutation events inside of the use element and pass them (propagate)
> into the <use>d element in the shadow tree via
> getInstanceRoot().correspondingElement.
Yes, this is more or less what I was proposing. I would have used
a WeakHashMap to maintain the correlation between referenced elements
(key) and referencing element (element instance). Otherwise you would
have to walk the subtree checking the correspondingElement. This
does potentially cause memory issues - hence the WeakHashMap.
>> 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.
>
> I think in either case the subtree has to be cloned (at least
> initially). Primarily because the attributes inherited from the <use>
> still need to be attached to the subtree (different for each reference
> to the element). Also, it is possible to make modifications to the
> subtree that need to be known to the use... I will try to find a good
> example of this...
What I was suggesting is that rather than creating a true clone
(which is what we currently do) I was just going to have the
ElementInstance tree. They would not copy the XML Attributes they
would always fetch them from the corresponding element, but they
would have a StyleMap (which is what the CSS cascade uses) which was
derived off the use element.
>> Why do you think it needs a 'g' if the use element is referencing
>> a single element I don't see the need.
>
> This is primarily from reading
> http://www.w3.org/TR/SVG/struct.html#UseElement#UseElement In the
> "Otherwise:" section. But now on re-reading it I suppose that it could
> be interpreted differently: e.g. it is recommending a way to handle the
> visual appearance-- but in reality there is no need to wrap with a <g>.
> In effect though I find it easier to wrap the element in the <g> because
> of attributes like style. If there is a style attribute in the <use> and
> in the referenced element that set different properties, overwriting the
> referenced element's style attribute is bound to lose information.
We don't need to copy the attributes over because the clone tree is
a child of the use element so we don't need to copy the use style over
into the subtree it just inherits via CSS as normal.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re:
Posted by Jeff Rafter <li...@jeffrafter.com>.
Hi Thomas
> I would not say there was a major hurdle to overcome. It just
> hasn't been a major issue to date.
That is good to know!
> 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.
I think in general it is sub-optimal but a workable solution (the method
you propose lower is much better).
> 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...
Sounds good.
> 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 sounds excellent. A low-end solution would be to simply handle the
four mutation events inside of the use element and pass them (propagate)
into the <use>d element in the shadow tree via
getInstanceRoot().correspondingElement.
> 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.
I think in either case the subtree has to be cloned (at least
initially). Primarily because the attributes inherited from the <use>
still need to be attached to the subtree (different for each reference
to the element). Also, it is possible to make modifications to the
subtree that need to be known to the use... I will try to find a good
example of this...
> 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.
Good to know-- in general I despise shadow trees.
> Why do you think it needs a 'g' if the use element is referencing
> a single element I don't see the need.
This is primarily from reading
http://www.w3.org/TR/SVG/struct.html#UseElement#UseElement In the
"Otherwise:" section. But now on re-reading it I suppose that it could
be interpreted differently: e.g. it is recommending a way to handle the
visual appearance-- but in reality there is no need to wrap with a <g>.
In effect though I find it easier to wrap the element in the <g> because
of attributes like style. If there is a style attribute in the <use> and
in the referenced element that set different properties, overwriting the
referenced element's style attribute is bound to lose information.
> I'd be happy to help but to contribute this back you would need to
> have a CLA on file.
Alright... I will look into that.
Thanks,
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re:
Posted by Thomas DeWeese <Th...@Kodak.com>.
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: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org