This covers the "hairy" parts. Complex deep references, circular
references,
self-references. All test work excellent w/o crashs or leaks.
How about cases like this:
- <use> referencing <g> which contains another <use> referencing
something else (valid double use chain).
- valid <use> chains of larger size, like 2 or 3
- <use> inside one <g> referencing another <g> which contains a
<use> reference back to the original <g> (loop with two <use>
elements referencing each other's parents)
- <use> inside a marker
- <use> referencing a path with markers
- <use> referencing a path with markers which themselves contain
<use> references (valid ones)
- <use> referencing a path with markers which themselves contain
<use> references to a parent of the original <use> (invalid loop
via markers)
I'm sure there must be other complex cross-referencing cases along
these lines.
Dealing with loops is relatively trivial (we already have do this for
the toString and join methods on JS/DOM arrays) so i don't think
those are significant problems (though obviously we would need a few
test cases to ensure that we actually stop them -- saying we have,
when we haven't would cause badness). Briefly the paint method would
require (very-pseudo-code, and i'm not sure whether this logic should
occur in the paint code, or when constructing the render tree)
SVGUseElemenT::paint(...)
{
static HashSet<SVGUseElement*> paintedElems;
if (paintedElems.contains(this))
return;
paintedElems.add(this)
...
magical painting code
...
paintedElems.remove(this)
}
Now this might cause us to incorrectly filter out some nodes (i
vaguely recall svg provides a few flow control structures, which
might in effect cause they same use element to render differently in
different cases, i haven't really looked into it). That said, I
doubt this will occur in a significant number of cases, and in the
mean time at least this seems to be an acceptable mechanism for
preventing looping badness.
As for the non-looping issues, i haven't really though about it in
enough detail to be able to comment
--Oliver
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
