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 jonathan wood <jo...@gmail.com> on 2010/02/10 15:21:43 UTC
continued contribution discussion ... Thomas' To Do List
Hello Dev,
I've clipped Thomas' todo list and pasted below for reference. I'll just
refer to the numbers.
My paying gig would benefit from all of the below, so I'm ordering based
on personal preference. If one task is more useful to a larger audience,
I'm cool with refocusing.
Task 4 is one I'd like to tackle first. I do have some concerns though.
Would we continue to support the shadowtree api? I would assume so since
much code probably relies on the voodoo-traversal to the real parent. Since
the computational overhead of supporting the spec and the shadowtree may be
significant, should the shadowtree api be refactored to mimic the old
behavior while really traversing elementinstance's? Are there any test
cases for the shadowtree to test for regression?
Task 3 probably the most interesting to me. Thomas, do you happen to know
where the gradient example might have landed if not on trunk. I can dig if
you are not sure.
1 & 2 look pretty straightforward.
Jonathan
1) Pipe all element "lookups" through an object associated with the
BridgeContext. This would be to serve two purposes. First it
would more easily enable people to 'replace' Batik's lookup/fetch
logic (replacing/augmenting ParsedURL only goes so far). Second
if paired with 'unlookup' calls it would enable Batik to detect
complex reference loops in content (an element that references a
pattern that uses the element).
2) Make everything use ParsedURL for references. Currently there
are still a few places where we don't use ParsedURL (I think
mostly in CSS) this mostly means that you can't use base64
encoded URLS in these places.
3) Add dynamic updates for referenced content. Currently in many
cases if a referenced element changes Batik doesn't notice. I
think this is true for patterns, filters, masks, etc. I did an
example of dependency tracking for gradients (which may not have
landed on trunk) at some point it would be nice if this was extended
to other areas.
4) Implement ElementInstance for Use elements. Currently we create a
shadow tree to support the use element, which is not conformant to
the SVG specification. It would be better if we created ElementInstances
that could carry the CSS cascade information and then use a reference
to the actual element for DOM attributes. This would require updating
all of the Bridges to know/handle the ElementInstance case but I think
the changes (while widespread) could be fairly simple.
Re: continued contribution discussion ... Thomas' To Do List
Posted by th...@kodak.com.
Hi Jonathan,
jonathan wood <jo...@gmail.com> wrote on 02/10/2010 09:21:43
AM:
> My paying gig would benefit from all of the below, so I'm ordering
> based on personal preference. If one task is more useful to a
> larger audience, I'm cool with refocusing.
Cool!
> Task 4 is one I'd like to tackle first. I do have some concerns
> though. Would we continue to support the shadowtree api? I would
> assume so since much code probably relies on the voodoo-traversal to
> the real parent.
Hmmm... You got me thinking about this. I now remember that
Cameron did a bunch of work to implement XBL which used and perhaps
exposed in a different way aspects of the shadow tree.
Since the computational overhead of supporting the
> spec and the shadowtree may be significant, should the shadowtree
> api be refactored to mimic the old behavior while really traversing
> elementinstance's?
I think essentially all of Batik's internal traversals rely on
batik.css.engine.CSSNavigableNode to walk the shadow tree, I don't
think that should really change. What can change however is that
in some cases you will get back an ElementInstance rather than an
SVG Element. One thing I'm hoping is that we can make the 'use'
element a little less expensive (memory wise) by not having to copy
the entire SVG tree.
> Are there any test cases for the shadowtree to test for regression?
Not directly, but all of content that uses the 'use' element will
effectively test the shadow tree stuff.
> Task 3 probably the most interesting to me. Thomas, do you happen
> to know where the gradient example might have landed if not on
> trunk. I can dig if you are not sure.
I think it can be found at:
https://svn.apache.org/repos/asf/xmlgraphics/batik/branches/depend-track
The commit was made in late Oct 2006 so I'm not sure how cleanly it
will
move over to trunk. Also I forget what issues might be lurking. You
might
check the mail-lists from around that time, since I probably sent a note
summarizing the work.
> 1 & 2 look pretty straightforward.
Yes, they should be fairly normal refactoring tasks.
> 1) Pipe all element "lookups" through an object associated with the
> BridgeContext. This would be to serve two purposes. First it
> would more easily enable people to 'replace' Batik's lookup/fetch
> logic (replacing/augmenting ParsedURL only goes so far). Second
> if paired with 'unlookup' calls it would enable Batik to detect
> complex reference loops in content (an element that references a
> pattern that uses the element).
>
> 2) Make everything use ParsedURL for references. Currently there
> are still a few places where we don't use ParsedURL (I think
> mostly in CSS) this mostly means that you can't use base64
> encoded URLS in these places.
>
> 3) Add dynamic updates for referenced content. Currently in many
> cases if a referenced element changes Batik doesn't notice. I
> think this is true for patterns, filters, masks, etc. I did an
> example of dependency tracking for gradients (which may not have
> landed on trunk) at some point it would be nice if this was extended
> to other areas.
>
> 4) Implement ElementInstance for Use elements. Currently we create a
> shadow tree to support the use element, which is not conformant to
> the SVG specification. It would be better if we created
ElementInstances
> that could carry the CSS cascade information and then use a reference
> to the actual element for DOM attributes. This would require
updating
> all of the Bridges to know/handle the ElementInstance case but I
think
> the changes (while widespread) could be fairly simple.
Re: continued contribution discussion ... Thomas' To Do List
Posted by Helder Magalhães <he...@gmail.com>.
Hi Jonathan,
> Task 4 is one I'd like to tackle first. [...]
>
> Task 3 probably the most interesting to me. Thomas, do you happen to know
> where the gradient example might have landed if not on trunk. I can dig if
> you are not sure.
>
> 1 & 2 look pretty straightforward.
FWIW, all of them seem interesting. Task 3 is also the one I find most
interesting in terms of functionality (i.e., it has been a long
standing issue/limitation in the framework, periodically asked for in
the mailing list). :-)
On the other hand, some refactoring is usually a good idea to
strengthen the base before entering an important development cycle.
I'm also trying to tackle some tweaks in the (SVN) repository,
documentation, etc. in the hope of helping improve this. (I'll post
something about that in a separate thread whenever possible.) ;-)
I'd hold for some more feedback (Thomas? Cameron?) but, in the
meantime, I'll be watching and trying to give a hand on what I'm able
to (mostly a couple more eyeballs reviewing the patches and possibly
testing them as well). :-)
> Jonathan
Cheers,
Helder
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org