Bug 19312 - SVG hit testing is *way* too slow
: SVG hit testing is *way* too slow
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: SVG
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-29 10:57 PDT by Eric Seidel
Modified: 2010-05-05 00:31 PDT (History)
4 users (show)

See Also:


Attachments
test case (sorta a layout test, not quite) (2.54 KB, image/svg+xml)
2008-05-29 10:58 PDT, Eric Seidel
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

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel 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).
Comment 1 Eric Seidel 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.
Comment 2 Simon Fraser (smfr) 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.
Comment 3 Simon Fraser (smfr) 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.
Comment 4 Simon Fraser (smfr) 2009-01-02 15:30:08 PST
See also bug 15393.
Comment 5 Dirk Schulze 2009-12-30 13:36:02 PST
*** Bug 15704 has been marked as a duplicate of this bug. ***
Comment 6 Dirk Schulze 2009-12-30 13:44:11 PST
(In reply to comment #3)
> 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.

Will the patch on bug 30055 fix this?
Comment 7 Dirk Schulze 2010-05-04 12:49:40 PDT
Created attachment 55039 [details]
Patch
Comment 8 Dirk Schulze 2010-05-04 12:50:58 PDT
(In reply to comment #7)
> Created an attachment (id=55039) [details]
> Patch

This is a huge speed-up of the test attached to this br.
Comment 9 Nikolas Zimmermann 2010-05-04 13:06:48 PDT
Comment on attachment 55039 [details]
Patch

Looks great to me, as discussed before :-) r=me.
Comment 10 Dirk Schulze 2010-05-05 00:31:46 PDT
Comment on attachment 55039 [details]
Patch

Clearing flags on attachment: 55039

Committed r58804: <http://trac.webkit.org/changeset/58804>
Comment 11 Dirk Schulze 2010-05-05 00:31:57 PDT
All reviewed patches have been landed.  Closing bug.