Bug 75861

Summary: [Chromium] JPEG RGB swizzling order should match platform pixel format
Product: WebKit Reporter: Sami Kyostila <skyostil>
Component: ImagesAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: hbono, kbr, noel.gordon, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 59670, 78323    
Attachments:
Description Flags
Patch none

Sami Kyostila
Reported 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.
Attachments
Patch (1.73 KB, patch)
2012-01-09 09:05 PST, Sami Kyostila 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Sami Kyostila
Comment 1 2012-01-09 09:05:58 PST
Created attachment 121675 [details] Patch
Kenneth Russell
Comment 2 2012-01-09 10:09:10 PST
Comment on attachment 121675 [details] Patch Looks fine as long as it's been tested.
Sami Kyostila
Comment 3 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.
WebKit Review Bot
Comment 4 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>
WebKit Review Bot
Comment 5 2012-01-09 11:46:50 PST
All reviewed patches have been landed. Closing bug.
noel gordon
Comment 6 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?
Sami Kyostila
Comment 7 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.
noel gordon
Comment 8 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?
noel gordon
Comment 9 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
Note You need to log in before you can comment on or make changes to this bug.