Summary: | Composited/HW content have the red and blue channels inverted in DRT on Chromium Android | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Peter Beverloo <peter> | ||||
Component: | Tools / Tests | Assignee: | 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
Peter Beverloo
2012-10-08 06:45:15 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. I seem to remember Alok ran into a channel swap in the compositor someplace. Don't know if it was related. 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. Created attachment 170652 [details]
Patch
Comment on attachment 170652 [details]
Patch
Hmm, so the byte order for kARGB_8888 is different on android, or the configuration itself is different?
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. 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.
Comment on attachment 170652 [details] Patch Clearing flags on attachment: 170652 Committed r132518: <http://trac.webkit.org/changeset/132518> All reviewed patches have been landed. Closing bug. |