Bug 47868 – Pixel cracks when using background image sprite on transformed element at certain scales.

• Status: RESOLVED
• Resolution: FIXED
• Component: Images

[Yongjun Zhang]

The following html code snippet will cause unwanted blue pixels around the div element in TOT at certain zoom levels:

<div style="-webkit-transform: scale(2.659); background-image: url(http://www.google.com/reader/ui/1225119760-lhn-sprite.png); height: 16px; width: 16px;"></div>

[Yongjun Zhang]

Created attachment 71112 [details]
Add a screenshot to show the unwanted pixels around div element.

Added a screenshot to show the pixel bleeding at the edge of div element.   Please note the two short blue lines at the right and bottom edge.

[Yongjun Zhang]

<rdar://problem/8020939>

[Yongjun Zhang]

Created attachment 71117 [details]
Change to sub-image path when CGContext has scale and sourceRect is not the same as destRect.

This patch has pixel test.   When I run it, the expected result is generated automatically under mac directory.  However, I am not sure what I should do for other ports.   Do I need to create expected png result for other ports?  Or at least the expected.txt file?

[Yongjun Zhang]

Dan suggested I should run pixel tests for fast/borders/border-image-rotate-transform.html.  However, in my machine, fast/borders/border-image-rotate-transform.html fails with or without this patch (the image diff is 0.2% with this patch, and 0.19% without this patch).

Comment on attachment 71117 [details]
Change to sub-image path when CGContext has scale and sourceRect is not the same as destRect.

View in context: https://bugs.webkit.org/attachment.cgi?id=71117&action=review

> WebCore/platform/graphics/cg/ImageCG.cpp:189
> +        bool hasScale = transform.a != 1.0f || transform.d != 1.0f;

WebKit style is to omit the “.0f”. It serves no useful purpose whatsoever.

This test criteria seem to be wrong. On the one hand, the (very common) flip transform is included, and on the other hand, a shear or skew transform, which is likely to require interpolation and therefore introduce bleeding, is excluded. AffineTransform::isIdentityOrTranslationOrFlipped() may be the right test here.

[Yongjun Zhang]

Created attachment 71191 [details]
revised patch, use AffineTransform::isIdentityOrTranslationOrFlipped() to test if sub-image is needed.

[Simon Fraser (smfr)]

Comment on attachment 71191 [details]
revised patch, use AffineTransform::isIdentityOrTranslationOrFlipped() to test if sub-image is needed.

View in context: https://bugs.webkit.org/attachment.cgi?id=71191&action=review

> WebCore/platform/graphics/cg/ImageCG.cpp:189
> +            CGAffineTransform transform = CGContextGetUserSpaceToDeviceSpaceTransform(context);

Is CGContextGetUserSpaceToDeviceSpaceTransform() the right thing to test? What if you're rendering into a compositing layer (CALayer)? Why not just check the GraphicsContext getCTM?

[Yongjun Zhang]

Created attachment 71217 [details]
Revised patch: Use GraphicsContext::getCTM() instead of CGContextGetUserSpaceToDeviceSpaceTransform() since getCTM() could be more efficient.

[WebKit Commit Bot]

Comment on attachment 71217 [details]
Revised patch: Use GraphicsContext::getCTM() instead of CGContextGetUserSpaceToDeviceSpaceTransform() since getCTM() could be more efficient.

Clearing flags on attachment: 71217

Committed r70118: <http://trac.webkit.org/changeset/70118>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.