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 Cameron McCormack <ca...@aka.mcc.id.au> on 2005/05/26 06:28:26 UTC
Dependency tracking
Hi Thomas.
I was looking through my sXBL code today, which is still in its same
state as a few months ago, and I'm going to start cleaning it up so I
can think about committing it some time soon.
One annoying thing though is that I have event listeners all over the
place, and I'm sure I haven't got all that I need yet to be completely
correct. I remember you mentioning that it would be good to have a
dependency tracking system that could simplify this sort of thing. So I
was wondering if you could list some places where this could be used.
If it'll do a good job of simplifying listeners and updates then I'll
refactor my sXBL code to use it (after I write it ;)).
Here's a few areas I can think of to start with:
- Rebuilding GVT trees when an applicable attribute changes
- Rebuilding GVT trees when CSS properties change
- Tracking xlink:hrefs and IDs
- Tracking xml:base changes
- Maybe do use element without cloning?
Anything else that might benefit? Looking at, for example, this bug:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23443
what were the problems in doing the complete tracking of gradients that
reference other gradients?
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Dependency tracking
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
> > - Tracking xlink:hrefs and IDs
>
> Hadn't really thought about this one - does anyone
> really change "id's" on the fly???
Yup, in my case SVG Graphics Editor. This authoring tool allows the user
to change the id.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Dependency tracking
Posted by Thomas DeWeese <Th...@Kodak.com>.
Cameron McCormack wrote:
> I was looking through my sXBL code today, which is still in its same
> state as a few months ago, and I'm going to start cleaning it up so I
> can think about committing it some time soon.
Ok good. Since I think the SVN switch is coming soon I figure
we will merge after switching to SVN (I just get the feeling this
will be easier and cleaner).
> One annoying thing though is that I have event listeners all over the
> place, and I'm sure I haven't got all that I need yet to be completely
> correct.
I'd also be a bit surprised if you managed to clean them all up
properly when things change...
> I remember you mentioning that it would be good to have a
> dependency tracking system that could simplify this sort of thing. So I
> was wondering if you could list some places where this could be used.
> If it'll do a good job of simplifying listeners and updates then I'll
> refactor my sXBL code to use it (after I write it ;)).
I'll do my best although I must admit that one of the main reason
my attempts at implementing it have failed in the past is that as
soon as I start writing it, what it is and needs to be starts morphing
under me - signifying that I clearly don't fully understand the
problem, or I am trying to do too much at once. Anyway at the
risk of contaminating you with potentially bad ideas...
> Here's a few areas I can think of to start with:
>
> - Rebuilding GVT trees when an applicable attribute changes
> - Rebuilding GVT trees when CSS properties change
Just to clarify we don't generally rebuild entire GVT trees or
nodes when properties or attributes change. At least not in the
cases that I'm most interested in (I'll get back to this).
> - Tracking xlink:hrefs and IDs
Hadn't really thought about this one - does anyone
really change "id's" on the fly???
> - Tracking xml:base changes
Heh ;) when I read the discussion on this in
www-svg I was just thinking to myself (shoot me now!
shoot me now! - in my best Daffy Duck voice).
> - Maybe do use element without cloning?
Yes.
> Anything else that might benefit? Looking at, for example, this bug:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23443
>
> what were the problems in doing the complete tracking of gradients that
> reference other gradients?
Let's take this as it was the 'simple' case that I have
tried in the past to implement dependencies for. The way
'fill' works right now for updates is that when the CSSEngine
detects a change in a property value it notifies the BridgeContext
through the CSSPropertiesChangedListener which in the simple
case just calls handleCSSEngineEvent on the Bridge for the
Element. This method usually has a switch on what property
changed and then goes and updates the appropriate 'trait' on
the GVT node. So if any of stroke-width, stroke-dasharray, etc
change then the BasicStroke (and I think the stroke paint) are
rebuilt and the GVT node is updated in place.
The problem is that for complex paints like gradients the
fill property doesn't have to change on the element for the
gradient to change. The fill property is just one of many
possible dependencies. What makes gradients hard is that like
many elements in SVG you can 'chain' them. So a gradient
can have an xlink:href that refers to another gradient which
actually provides the stop colors for example:
<radialGradient id="rgDefaults">
<stop offset="0" stop-color="gold" />
<stop offset="1" stop-color="crimson" />
</radialGradient>
<radialGradient id="rgSpecifiedDefaults"
gradientUnits="objectBoundingBox"
cx="50%" cy="50%"
r="50%"
fx="50%" fy="50%"
spreadMethod="pad" xlink:href="#rgDefaults" />
So you can't just have one change listener you have to
have one for every gradient element in the 'chain' as any one could
have it's xlink:href changed at any time. Further you need to take
care to remove all 'down stream' listeners when an xlink:href changes.
Also note that within the gradient a color change might be triggered
through the CSS cascade (if for example current-color was used),
so just registering a DOM listener is insufficient.
Because the 'dependent thing' can so easily switch between
CSS and XML it seems that we really need a more unified system for
registering interest in changes than the existing split DOM/CSS.
Also unlike DOM events our CSS events currently don't "bubble".
My vision of what this system might look like is that you
would 'bracket' the creation of the 'trait' objects on GVT nodes
so that as the code accessed the various properties/attributes
(probably through custom functions) the dependencies would
automatically be tracked and collected so when you call the
end method of the bracket you would get an object back that could
notify you when any of the 'inputs' change (let's call it a
Tracker object). In my mind the tracker object would get associated
with a soft reference to the generated 'trait' object so if the
trait object ever goes to GC all the listeners, etc could be
cleared. It would probably be a good idea for the trackers to
be 'nestable' - so 'higher level' things can depend on several
lower level things (there are some issues like if the generated
trait for a tracker goes away can it go away if it's feeding
dependencies to other trackers? Part of me says yes since if
the generated trait became 'invalid' then probably anyone interested in
stuff that changed the trait is invalid). There is also an
issue of efficiency - for a simple change of the fill color
it would be unfortunate if we had to keep creating new tracker
objects - but perhaps we have to accept that for a while...
An alternate version of this which could be just another layer
on top of this. Would be to have a 'trait provider' where
essentially you tell it I need you to provide a fill trait to me for
this Element in the tree. It would compute one on the spot and 'push'
new versions of the fill as needed (probably based on something like
the 'trackers' above. In many ways this is the role the bridges
currently play (they 'push' new fill's to the GVT nodes) - but it
is probably finer grained - instead of a ShapeNodeBridge you would
have a FillBridge, StrokeBridge, PathBridge etc, the current
ShapeNodeBridge would then mostly play the role of associating the
various lower level bridges with the GVTNode.
If we go this route it would also be really nice to use
the dependency system to enable the GVT and DOM tree's to 'drift'.
So when the 'x' attribute on a rect changes rather than immediately
recomputing the path, fill and stroke (note we are conservative
in case they are gradients/patterns that depend on bbox - something
good dependencies could help with). It would set a flag indicating
that the shape 'trait' of the node is invalid. Then when the user
set's the 'y' attribute (as we know they will ;) all that happens
is that the shape 'trait' is marked dirty again - this repeats
for width and height. Then when a rendering is requested (or
some of the DOM calls like getBBox) all the dirty traits are
recomputed once.
On the topic of rebuilding tree's one of worst cases of this
is for changes in the width/height of SVG elements - currently
we trash the entire subtree (often essentially the whole document)
and rebuild on the off chance that someone used a percentage for
width/height... Bleh!
Finally in CSS we are fairly cascade happy, in CSS you can
have selectors that depend on attributes and document structure
so we end up recascading large sections of the tree because we
have no dependency information for the selectors. This is actually
quite a bit harder than the above problem because it is likely
that attribute changes will "add dependencies" so you need
something that is almost the 'inverse' of the normal dependency
system; if attributes x goes to y and the element has a sibling
of type foo then recascade, But note that it starts with what
amounts to a 'normal' dependency on attribute 'x' changing to 'y'.
This is a bit of a mind dump so take your time sorting through
it, and I would expect lots of questions, most of which I probably
won't have good answers to.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org