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
[EMAIL PROTECTED]
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
