[webkit-dev] SVG Stabilization

[Eric Gouriou]

On Feb 25, 2007, at 16:26 , Oliver Hunt wrote:
[...]
> 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)
> }

  If space (one bit) is available and if painting is guaranteed to be  
single-threaded,
a simple boolean flag in the element should suffice for this purpose  
(is_being_painted).

  Given that a static HashSet doesn't solve the threading issue anyway,
the only issue is whether there is a bit available in the Elements and
if the objects can be (temporarily) mutated during painting.

  The actual code may have to deal with abnormal termination of the  
painting sequence
though (all flags must be cleared).

   Eric

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


-- 
Eric Gouriou                                         
eric.gouriou at pobox.com