On Feb 25, 2007, at 3:32 AM, Nikolas Zimmermann wrote:

Hey Maciej,

Seems like there is rough consensus around this plan. So I filed bugs
to disable the experimental features for now:
http://bugs.webkit.org/show_bug.cgi?id=12883

And to do some kind of additional testing/review of the various SVG
microsyntax parsers (it turns out there are a lot):
http://bugs.webkit.org/show_bug.cgi?id=12884

Perfect. I think this covers most cases.

Some people have suggested that <use> should also be left on. I think
to make this possible would require significant additional testing,
including test cases of unusual situations like circular references,
nested references, etc. If anyone wants to do that testing, feel
free, and ideally please document it with test cases. Note: rewriting
<use> in a completely different way is unlikely to make it more
suitable for prime time, since the biggest problem with it is that it
is new, relatively untested code.

Agreed, it's definately new code, though the scenarios you are mentioning
are covered by tests (LayoutTests/svg/custom). In detail:

SVGElementInstance tests / (SVG) DOM scripting:
use-elementInstance-event-target.svg
use-elementInstance-methods.svg
use-instanceRoot-modifications.svg
use-modify-container-in-target.svg
use-modify-target-container.svg
use-modify-target-symbol.svg
use-property-changes-through-dom.svg
use-property-changes-through-svg-dom.svg

All of these tests operate on the new SVGElementInstance interfaces.
(instanceRoot method of SVGUseElement, returns the root SVGElementInstance).

The built SVGElementInstance tree is tested automatically within
use-elementInstance-methods.svg (checks instance tree consistency)

event handling on <use>:
use-event-handler-on-referenced-element.svg
use-event-handler-on-use-element.svg

Tests the various ways to set up event listeners on <use> elements:
either on the <use> element itself, or on the referenced element.
events have to be propagated to the SVGElementInstance (!) object, not
the original referenced element, nor our internal clone.

<use> on <use> tests:
use-forward-refs.svg
use-recursion-1.svg (<use> on <g> which references the <use> itself again.)
use-recursion-2.svg (<use> direct self-referencing>
use-recursion-3.svg (<use> on <g>, containing a <use> which references itself) use-recursion-4.svg (same like -3.svg, but one level deeper referencing)

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.

I'd also like to hear from others what they think of this level of testing. For now I will disable <use> along with other experimental features, but we could bring it back, given evidence of sufficient testing.

Regards,
Maciej



Simple <use> examples (no deep referencing):
use-on-g-containing-use.svg
use-on-g.svg
use-on-rect.svg
use-on-symbol-inside-pattern.svg
use-on-symbol.svg
use-on-text.svg
use-on-use.svg

The usual suspects: simple tests - w/o fancy features.

Misc:
use-events-crash.svg
use-symbol-overflow.svg
use-transform.svg

Other simple tests.

--
I hope the <use> on <use> tests are quite sufficient to test the tricky parts
of the new SVGUseElement / SVGElementInstance code.

I'd like to invent anyone interessed to stress test the <use> code.
We're already much better than Opera/FF/Batik (yes even Batik) with the
current implementation - and all it needs is heavy testing IMHO.

Niko

P.S. The only known <use> problem is that the event dispatching is not
completely implemented. IIRC the last missing issue is: (quote from 1.1 spec)

"An element and all its corresponding SVGElementInstance objects share an event listener list. The currentTarget attribute of the event can be used to
determine through which object an event listener was invoked."
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to