[webkit-dev] SVG Stabilization

[Oliver Hunt]

>>
>> 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