348296 - Nested <svg:svg> takes exponentially long to render

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060806 Minefield/3.0a1

This testcase shows that nested <svg:svg> elements take exponentially long to render.  For example, 12 nested <svg:svg> elements make Firefox hang for about 12 seconds.

Nesting level -> time

9  ->   457 ms
10 ->  1444 ms
11 ->  3728 ms
12 -> 11983 ms

Comment 1

[Jesse Ruderman]

Attachment: testcase

Comment 2

[tor]

There's a small typo in the testcase that causes us problems - "viewbox" instead of "viewBox".

Comment 3

[tor]

Attachment: problematic call cycle

Comment 4

[tor]

Attachment: remove looping

Remove cause of looping.

Seems to pass testing of modifying the hierarchy.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why didn't you make it an SVG image? :-)

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why didn't you make it an SVG image? :-)

Can you explain to me what's really going on here?

Comment 7

[tor]

(In reply to comment #5)
> Why didn't you make it an SVG image? :-)

kcachegrind exports PS, and given the low quality of that versus the in-program version I didn't feel it merited much further work.

Comment 8

[tor]

(In reply to comment #6)
> Can you explain to me what's really going on here?

The initial update of a <svg:svg> element calls UpdateCoordCtx(),
which through SetParentCoordCtx() updates the viewbox rectangle in
this case because the "viewBox" attribute is not set.  This triggers a
notification to the frame (NotifyViewportChange()), which calls
NotifyCanvasTMChanged() on the children to invalidate the cached
transformation matrix.  This method called UpdateCoordCtx(), causing
the loop to repeat on the children.

Comment 9

[tor]

Checked in.

Comment 10

[Jesse Ruderman]

See also bug 408147 -- a similar static testcase hangs trunk.