diff options
author | msarett <msarett@google.com> | 2016-02-11 08:41:53 -0800 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2016-02-11 08:41:53 -0800 |
commit | ef02b24d1c19bebe77ed6f4d531e245db45551c5 (patch) | |
tree | fc7f3ed381875ff6f889fb76c10031cfcc8b1106 /src/codec/SkBmpCodec.cpp | |
parent | 4946b9419f650ef7a2dc684ce98bb771e1ce8f40 (diff) |
Clarify bmp comment about when we support the alpha mask
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1689183002
Review URL: https://codereview.chromium.org/1689183002
Diffstat (limited to 'src/codec/SkBmpCodec.cpp')
-rw-r--r-- | src/codec/SkBmpCodec.cpp | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/src/codec/SkBmpCodec.cpp b/src/codec/SkBmpCodec.cpp index 3302e4f752..4828f7f7e2 100644 --- a/src/codec/SkBmpCodec.cpp +++ b/src/codec/SkBmpCodec.cpp @@ -373,9 +373,13 @@ bool SkBmpCodec::ReadHeader(SkStream* stream, bool inIco, SkCodec** codecOut) { // of the image to use the alpha channels. However, many of these images // leave the alpha channel blank and expect to be rendered as opaque. This // is the case for almost all V3 images, so we render these as opaque. For - // V4+, we will use the alpha channel, and fix the image later if it turns - // out to be fully transparent. - // As an exception, V3 bmp-in-ico may use an alpha mask. + // V4+ images in kMask mode, we will use the alpha mask. + // + // skbug.com/4116: We should perhaps also apply the alpha mask in kStandard + // mode. We just haven't seen any images that expect this + // behavior. + // + // Additionally, V3 bmp-in-ico may use the alpha mask. SkAlphaType alphaType = kOpaque_SkAlphaType; if ((kInfoV3_BmpHeaderType == headerType && inIco) || kInfoV4_BmpHeaderType == headerType || |