Bug 52335 – [Chromium] Bleeding/incorrect edge pixels when scaling images on Snow Leopard

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Images

[Mihai Parparita]

Created attachment 78756 [details]
Screenshot

Load http://trac.webkit.org/export/75656/trunk/LayoutTests/css2.1/t0803-c5502-mrgn-r-00-c-ag.html and inspect with the DigitalColor Meter the pixels to the right of the bottom edge of the first bar. They should be pure white, but instead they appear as FDFBFB. This is in the portion of the test that uses http://trac.webkit.org/export/75656/trunk/LayoutTests/css2.1/support/swatch-white.png, which is a 15x15 pure white image that is being re-scaled to 48x10.

This only appears to happen with Chromium on Snow Leopard, Chromium on Leopard and the mac port on either one don't have this problem. It doesn't happen if the scaled size is 15x10 or 48x15.

Cc-ing Adam since the image decoders (which the Mac port doesn't use) could somehow be implicated.

[Mihai Parparita]

I think this is a CG bug, since I can get the same behavior in a simple standalone program. It happens with kCGInterpolationDefault/High/Medium, but not with kCGInterpolationLow.

I still don't see why this doesn't happen with the mac port on Snow Leopard though.

[Mihai Parparita]

I have attempted to make mac and chromium-mac as consistent as possible, but I'm still unable to figure out why only chromium-mac gets this weird interpolating behavior:

- I switched the PNG image from indexed color to RGBA (chromium-mac always creates CGIMages that are RGBA, but the mac port loads images using CoreGraphics and still had the CGImage with an indexed color space)
- I switched the chromium-mac image from kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host to  kCGImageAlphaLast (to match the mac port)

All other attributes (CGImageShouldInterpolate, CGImageGetRenderingIntent) are the same.

The only difference that I can think of at this point is that the GraphicsContext/CGContext that we're drawing into is somehow different but I'm not sure where that's set up.

+Avi in case he has any ideas.

[Mihai Parparita]

It looks this is a x86_64 vs. i386 difference. If I open Safari in 32-bit mode (or use a 32-bit app that embeds WebKit, like BBEdit), then it has the same edge artifact as Chrome. I assume Core Graphics is ending up on different scaling code paths.

There may not much we can do about this in that case (though if I can get a small enough test-case I'll file an Apple bug), we'll just have to have different chromium-mac baselines for these tests.

[Mihai Parparita]

I reported this to Apple as rdar://8862753 (visible at http://openradar.appspot.com/8862753).

[Mihai Parparita]

And rebaselined tests affected by this with http://trac.webkit.org/changeset/75762 (since they're currently passing on Leopard, and I figured we didn't want to lose coverage).

[Stephen Chenney]

Test related bugs being marked WontFix. TestExpectations will contain bug if still relevant.