Fixes for SkAlphaTypes.
authorscroggo <scroggo@google.com>
Thu, 5 Jun 2014 18:18:04 +0000 (11:18 -0700)
committerCommit bot <commit-bot@chromium.org>
Thu, 5 Jun 2014 18:18:05 +0000 (11:18 -0700)
commit0187dc2155830c1ae3390d97463d5dd3971eca41
tree784e9e83ad6957d361a5c161ca70ec22da6de43e
parentb144271179aaf82cb1151e9dfd8e866747402594
Fixes for SkAlphaTypes.

When using allocPixels to set the info and create a new pixelRef in one
shot, create the pixelRef with the corrected info of the bitmap (i.e.
alphatype).

Simplify the check to determine whether to copy the genID in SkBitmap::
copyTo's same configs/same sizes case. The old logic (only checking the
height and assuming the others must be the same) relied on a deep
(mis?)understanding of the rest of the function, and I cannot convince
myself that it has to be true, given that readPixels may have switched
src to a different SkBitmap. Instead, just compare the SkImageInfos,
which is much clearer. (This also caught a bug where a 565 bitmap had
the wrong alphatype, leading to the allocPixels fixes.)

If readPixels succeeds but the source is unpremultiplied, fail out
of copyTo, since readPixels assumes premultiplied.

When copying from 8888 to 4444 or in the fallback case of drawing,
return false if the alphatype is unpremul, which would have failed
anyway.

BUG=skia:2012
R=reed@google.com, bsalomon@google.com

Author: scroggo@google.com

Review URL: https://codereview.chromium.org/317053003
src/core/SkBitmap.cpp