We name our .pngs by pixel hashes for gold. For 8888 images, we're hashing
SkPMColors, which have platform-dependent order: BGRA on Linux and Windows,
RGBA otherwise. This means we can end up with pixel-identical pngs with
different hashes, which is confusing.
This CL standardizes on RGBA for 8888 configs, arbitrarily chosen so that
Android ends up a no-op. Long-term, this should eliminate most of the
0-pixel-diff problems we see on gold.skia.org. There are other ways to end up
with the same .png from different SkBitmaps (think, red 565 square vs. red 8888
square) but they're rather less common / likely.
This will temporarily create a giant 0-pixel-diff problem on gold.skia.org.
Any Linux or Windows images which are not already pixel-identical to a Mac or
Android image should show up as untriaged hashes that are pixel-identical to
their version just before landing (we're only changing the hash, not the .png).
This means anything vaguely platform dependent (fonts, GPUs) will probably show
up as needing a triage but with a zero diff from a previous image.
If this goes well, we might do the same for 565. Just want to leave them out
for now to cut down on the triaging I need to do in one go.
BUG=skia:
Review URL: https://codereview.chromium.org/
1226933005
hash.writeStream(data, data->getLength());
data->rewind();
} else {
- hash.write(bitmap.getPixels(), bitmap.getSize());
+ // If we're BGRA (Linux, Windows), swizzle over to RGBA (Mac, Android).
+ // This helps eliminate multiple 0-pixel-diff hashes on gold.skia.org.
+ // (Android's general slow speed breaks the tie arbitrarily in RGBA's favor.)
+ // We might consider promoting 565 to RGBA too.
+ if (bitmap.colorType() == kBGRA_8888_SkColorType) {
+ SkBitmap swizzle;
+ SkAssertResult(bitmap.copyTo(&swizzle, kRGBA_8888_SkColorType));
+ hash.write(swizzle.getPixels(), swizzle.getSize());
+ } else {
+ hash.write(bitmap.getPixels(), bitmap.getSize());
+ }
}
SkMD5::Digest digest;
hash.finish(digest);