Bug 95197 – Incorrect large-area clipping

• Component: SVG
• Status: RESOLVED FIXED

[Florin Malita]

Created attachment 160968 [details]
Incorrect clipping

CR issue: http://code.google.com/p/chromium/issues/detail?id=144630

This bug manifests when the following conditions are met:

a) the clipping is handled via masking (forcing it via clip-path on a clip-path in the test)
and
b) the clip area is larger than 4096 (absolute size) in one dimension
and
c) the path repaint rect has a non-zero offset

During mask ImageBuffer allocation the size is limited to 4096x4096 max. This introduces a non-trivial scaling component, which needs to be accounted for in the translation also.

Note that this also affects masking, which uses the came ImageBuffer allocation logic.

[Florin Malita]

Created attachment 160969 [details]
Incorrect masking

[Florin Malita]

(In reply to comment #0)
> During mask ImageBuffer allocation the size is limited to 4096x4096 max. This introduces a non-trivial scaling component, which needs to be accounted for in the translation also.

I think the order of matrix ops in SVGRenderingContext::createImageBuffer() is wrong:

* imageContext->translate()
* imageContext->concatCTM)()
* imageContext->scale()

Since this is a viewport transformation (where the viewport is the image buffer and world coords == abs coords), the scaling transform should be pushed before translation: P' = S(T(P)) = S * T * P

Some quick testing validates this, patch coming soon.

[Florin Malita]

Created attachment 160988 [details]
Patch

[Nikolas Zimmermann]

Comment on attachment 160988 [details]
Patch

r=me, this was obviously wrong.

[WebKit Review Bot]

Comment on attachment 160988 [details]
Patch

Clearing flags on attachment: 160988

Committed r126993: <http://trac.webkit.org/changeset/126993>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Jessie Berlin]

This test started failing on Mac at the point it was added:

http://build.webkit.org/results/Apple%20Lion%20Debug%20WK1%20(Tests)/r126993%20(2333)/results.html

Can you please check the results and see if they are expected for Mac? Otherwise I will need to roll this out.

[Florin Malita]

(In reply to comment #7)
> This test started failing on Mac at the point it was added:
> 
> http://build.webkit.org/results/Apple%20Lion%20Debug%20WK1%20(Tests)/r126993%20(2333)/results.html
> 
> Can you please check the results and see if they are expected for Mac? Otherwise I will need to roll this out.

Yes, the results are good. Unfortunately there's a small subpixel artifact on the edge which makes it different. I'll update it to try to avoid that.

[Florin Malita]

I've tweaked the reftest mask to hopefully take care of it: http://trac.webkit.org/changeset/127056

If that doesn't do it, we may need to switch this test to image results and possibly investigate why that bleeding happens.

[Jessie Berlin]

(In reply to comment #9)
> I've tweaked the reftest mask to hopefully take care of it: http://trac.webkit.org/changeset/127056
> 
> If that doesn't do it, we may need to switch this test to image results and possibly investigate why that bleeding happens.

Looks like r127056 took care of it. Thanks :)