Bug 98647

Summary: Composited/HW content have the red and blue channels inverted in DRT on Chromium Android
Product: WebKit Reporter: Peter Beverloo <peter>
Component: Tools / TestsAssignee: Sami Kyöstilä <skyostil>
Status: RESOLVED FIXED    
Severity: Normal CC: alokp, bsalomon, jamesr, senorblanco, skyostil, tomhudson, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 96398, 100263    
Attachments:
Description Flags
Patch none

Peter Beverloo
Reported 2012-10-08 06:45:15 PDT
Composited/HW content have the red and blue channels inverted in DRT on Chromium Android. To list a few examples: * http://build.webkit.org/results/Chromium%20Android%20Release%20(Tests)/r130632%20(1228)/css3/filters/effect-drop-shadow-hw-diffs.html Test: http://trac.webkit.org/export/130632/trunk/LayoutTests/css3/filters/effect-drop-shadow-hw.html * http://build.webkit.org/results/Chromium%20Android%20Release%20(Tests)/r130632%20(1228)/compositing/shadows/shadow-drawing-diffs.html Test: http://trac.webkit.org/export/130632/trunk/LayoutTests/compositing/shadows/shadow-drawing.html This also seems to happen to text content, such as in this result: * http://build.webkit.org/results/Chromium%20Android%20Release%20(Tests)/r130632%20(1228)/compositing/sibling-positioning-diffs.html Test: http://trac.webkit.org/export/130632/trunk/LayoutTests/compositing/sibling-positioning.html Normal images and texts are fine. As a point of interest here, the red and blue channels are being inverted by code in DumpRenderTree itself, but it seems that normal (non-accelerated) screenshots also take this path. http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Tools/DumpRenderTree/chromium/TestShell.cpp&l=676 Could it be that the SkCanvas in m_webViewHost->canvas() returns BGRA for hardware, RGBA for software paths?
Attachments
Patch (2.26 KB, patch)
2012-10-25 08:10 PDT, Sami Kyöstilä 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Brian Salomon
Comment 1 2012-10-08 07:13:30 PDT
I don't think it is a Skia issue as the SW skia backend is used for at least the third test (and possibly the second as well). I'd guess it has to do with invoking the compositor.
Stephen White
Comment 2 2012-10-08 10:41:07 PDT
I seem to remember Alok ran into a channel swap in the compositor someplace. Don't know if it was related.
Sami Kyöstilä
Comment 3 2012-10-09 08:40:13 PDT
I'm guessing there's a mismatch between the compositor's read back pixel format and what Skia/WebViewHost is expecting. We've had a few of these before so it's not entirely unlikely.
Sami Kyöstilä
Comment 4 2012-10-25 08:10:12 PDT
Created attachment 170652 [details] Patch
James Robinson
Comment 5 2012-10-25 12:21:26 PDT
Comment on attachment 170652 [details] Patch Hmm, so the byte order for kARGB_8888 is different on android, or the configuration itself is different?
Brian Salomon
Comment 6 2012-10-25 12:40:28 PDT
The macros SK_R32_SHIFT, SK_G32_SHIFT, etc that define the byte order of Skia's kARGB_8888 are set differently on Android than on other platforms.
James Robinson
Comment 7 2012-10-25 12:47:22 PDT
Comment on attachment 170652 [details] Patch OK, thanks for the clarification. Patch seems fine but I have a sneaking suspicious that this might not be the only place we have byte order problems.
WebKit Review Bot
Comment 8 2012-10-25 13:01:18 PDT
Comment on attachment 170652 [details] Patch Clearing flags on attachment: 170652 Committed r132518: <http://trac.webkit.org/changeset/132518>
WebKit Review Bot
Comment 9 2012-10-25 13:01:22 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.