Hi Jonathan,
jonathan wood <[email protected]> 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.
