Bug 75861 - [Chromium] JPEG RGB swizzling order should match platform pixel format
Summary: [Chromium] JPEG RGB swizzling order should match platform pixel format
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 59670 78323
  Show dependency tree / graph
 
Reported: 2012-01-09 08:56 PST by Sami Kyostila
Modified: 2012-02-10 14:40 PST (History)
4 users (show)

See Also:

Attachments
Patch (1.73 KB, patch)
2012-01-09 09:05 PST, Sami Kyostila 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sami Kyostila 2012-01-09 08:56:20 PST 
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.
Comment 1 Sami Kyostila 2012-01-09 09:05:58 PST 
Created attachment 121675 [details]
Patch
Comment 2 Kenneth Russell 2012-01-09 10:09:10 PST 
Comment on attachment 121675 [details]
Patch

Looks fine as long as it's been tested.
Comment 3 Sami Kyostila 2012-01-09 10:23:51 PST 
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.
Comment 4 WebKit Review Bot 2012-01-09 11:46:46 PST 
Comment on attachment 121675 [details]
Patch

Clearing flags on attachment: 121675

Committed r104472: <http://trac.webkit.org/changeset/104472>
Comment 5 WebKit Review Bot 2012-01-09 11:46:50 PST 
All reviewed patches have been landed.  Closing bug.
Comment 6 noel gordon 2012-01-09 16:46:08 PST 
(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?
Comment 7 Sami Kyostila 2012-01-10 03:12:50 PST 
(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.
Comment 8 noel gordon 2012-01-10 05:00:24 PST 
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?
Comment 9 noel gordon 2012-01-10 23:11:05 PST 
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