[webkit-dev] SVG Stabilization

[Maciej Stachowiak]

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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev