Bug 75861 – [Chromium] JPEG RGB swizzling order should match platform pixel format

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

[Sami Kyostila]

The fix for bug 59670 added a fast path for performing channel swizzling and JPEG decoding in a single step. The channel swizzling order (JCS_EXT_RGBX) is hard coded and may not match the platform's pixel format.

[Sami Kyostila]

Created attachment 121675 [details]
Patch

[Kenneth Russell]

Comment on attachment 121675 [details]
Patch

Looks fine as long as it's been tested.

[Sami Kyostila]

Comment on attachment 121675 [details]
Patch

Thanks. I've tested this on a platform where the channel ordering was reversed to what this code was previously expecting.

[WebKit Review Bot]

Comment on attachment 121675 [details]
Patch

Clearing flags on attachment: 121675

Committed r104472: <http://trac.webkit.org/changeset/104472>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[noel gordon]

(In reply to comment #3)
> Thanks. I've tested this on a platform where the channel ordering was reversed to what this code was previously expecting.

What/where is this skia-using little-endian platform with pixels in reverse order?

[Sami Kyostila]

(In reply to comment #6)
> (In reply to comment #3)
> > Thanks. I've tested this on a platform where the channel ordering was reversed to what this code was previously expecting.
> 
> What/where is this skia-using little-endian platform with pixels in reverse order?

This is the case on Android.

[noel gordon]

IC.  The Android port seems to be is covered by bug 66687 reading the webkit-dev threads on the subject

  https://lists.webkit.org/pipermail/webkit-dev/2011-December/018923.html
  https://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html

You have a builder http://build.webkit.org/builders/Chromium%20Android%20Release it seems, but nothing running the webkit tests.

The build needs the Android NDK according to the instructions.  The NDK contains Android's image encoder/decoder systems and that includes jpeg.  Your change suggests Android is now using libjpeg-turbo and the public WebKit jpeg image decoder, is that correct?

[noel gordon]

Off-line Sami answered yes, libjpeg-turbo is being used. Per https://bugs.webkit.org/show_bug.cgi?id=59670#c10, the "skia -> little-endian -> BGRA pixel skia bitmaps" assumption runs deep in chromium, so my concern is webkit test failures due to pixel endianness issues.  I suggested he watch the following WebKit/LayoutTests tests:

  fast/images/*
  fast/canvas/canvas-toDataURL*
  fast/canvas/toDataURL*
  canvas/philip/tests/2d.imageData.put.unchanged.html
  canvas/philip/tests/toDataURL*
  tables/mozilla/bugs/bug29314.html
  tables/mozilla/bugs/bug13169.html
  tables/mozilla/bugs/bug10565.html
  tables/mozilla/bugs/bug11026.html
  fast/repaint/backgroundSizeRepaint.html
  fast/repaint/block-layout-inline-children-replaced.html
  fast/repaint/clipped-relative.html
  fast/repaint/selected-replaced.html
  tables/mozilla/bugs/bug12908-1.html