Bug 84117 – SVG hit testing on scaled paths is broken.

• Component: SVG
• Status: RESOLVED FIXED

[Philip Rogers]

Created attachment 137455 [details]
Testcase

If we scale a very small (sub 0.5px) path up to a visible size, hit testing will not work properly.

Original bug: http://code.google.com/p/chromium/issues/detail?id=65238
Note: this only affects Skia-backed platforms.

[Philip Rogers]

After some investigation, this problem stems from doing hit testing in object-space instead of screen-space (aka pixels). The problem is only surfaced on Skia-backed platforms because Skia doesn't handle sub-pixel path hit tests.

I'd like to propose a fairly large change to SVG's hit testing code that switches to doing hit testing in screen space. This will probably mean doing away with nodeAtFloatPoint and we will no longer transform the pointer location into each node's local coordinate space because we can rely on bounding boxes.

I don't have a patch ready yet but I wanted to put this idea up for comments as I will be out for the rest of the week (WebKit contributors meeting!)

[Eric Seidel (no email)]

Why would we want to move away from object-space testing?

[Philip Rogers]

*** Bug 84452 has been marked as a duplicate of this bug. ***

[Philip Rogers]

Created attachment 138596 [details]
First-pass at fixing SkPathContainsPoint to work with sub-pixel accuracy

Attached is a first-pass at solving this issue in Skia, comments appreciated!

I earlier stated that hit testing in screen-space would be better but after discussing this f2f at the contrib meeting, my idea was flawed for several reasons. My new patch updates Skia to just scale the path up before doing raster hit testing.

[Eric Seidel (no email)]

Comment on attachment 138596 [details]
First-pass at fixing SkPathContainsPoint to work with sub-pixel accuracy

Seems reasonable to me.

[WebKit Review Bot]

Comment on attachment 138596 [details]
First-pass at fixing SkPathContainsPoint to work with sub-pixel accuracy

Attachment 138596 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12523478

New failing tests:
platform/chromium/virtual/gpu/canvas/philip/tests/2d.path.isPointInPath.edge.html
canvas/philip/tests/2d.path.isPointInPath.edge.html
platform/chromium/virtual/gpu/fast/canvas/pointInPath.html
svg/custom/stroke-width-click.svg
fast/canvas/pointInPath.html

[WebKit Review Bot]

Created attachment 138737 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Philip Rogers]

Created attachment 139007 [details]
Update to make this patch pass tests

Thanks for the review Eric! The linux test failure was real and I've updated the patch so it should pass all tests now. There are two changes from the previous patch:
1) Skia falls over with coords above 32767 and we were not taking into account that the mouse pointer may be above this in our scaled-up space. I'm now taking into account the mouse coordinates when determining the scale value.
2) Instead of taking the floor of the mouse point when converting to integer values, we need to round. floorf(0.5f + point) accomplishes this.

Do you mind taking one more look Eric?

[Eric Seidel (no email)]

Comment on attachment 139007 [details]
Update to make this patch pass tests

Clever.

[WebKit Review Bot]

Comment on attachment 139007 [details]
Update to make this patch pass tests

Clearing flags on attachment: 139007

Committed r115335: <http://trac.webkit.org/changeset/115335>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.