19312 – SVG hit testing is *way* too slow

RESOLVED FIXED 19312

SVG hit testing is *way* too slow

https://bugs.webkit.org/show_bug.cgi?id=19312

Summary SVG hit testing is *way* too slow

Eric Seidel (no email)

Reported 2008-05-29 10:57:43 PDT

SVG hit testing is *way* too slow See the attached test case. I think the major problem is that RenderPath::nodeAtPoint() does not to any sort of optimization (like checking against the bbox) before testing against fill contains. Thus for an example like the one in the test case, we end up doing hundreds if not thousands of unnecessary path containment tests (which may involve mallocs, etc).

Attachments
test case (sorta a layout test, not quite) (2.54 KB, image/svg+xml) 2008-05-29 10:58 PDT, Eric Seidel (no email)	no flags	Details
Patch (1.57 KB, patch) 2008-12-30 22:32 PST, Simon Fraser (smfr)	no flags	Details Formatted Diff Diff
Patch (1.59 KB, patch) 2010-05-04 12:49 PDT, Dirk Schulze	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Eric Seidel (no email)

Comment 1 2008-05-29 10:58:59 PDT

Created attachment 21416 [details] test case (sorta a layout test, not quite) See the attached test case. We don't really have a very good way to do perf-based layout tests. The attached test could be modified to be say PASS when it runs under a certain threshold or something.

Simon Fraser (smfr)

Comment 2 2008-12-30 22:32:27 PST

Created attachment 26329 [details] Patch This patch implements your suggestion, and removes much of the hit testing cost. However, repaint is still very expensive. Sharking found bug 23050.

Simon Fraser (smfr)

Comment 3 2008-12-30 22:44:47 PST

Repaint is very expensive because EVERYTHING repaints even if only a small area is dirtied.RenderPath::paint() does no short-circuiting if the relativeBBox() is not in the dirty rect.

Simon Fraser (smfr)

Comment 4 2009-01-02 15:30:08 PST