cb6bef0ad5
- This update includes font documentation. SkFont_Reference.bmh was generated by running: bookmaker -b docs -i include/core/SkFont.h -t This creates a placeholder for examples and additional documentation. - More work done to exclude experimental/private symbols. Symbols that include "experimental_", "legacy_", "private_", "temporary_", "deprecated_" as part of their name (case-insensitive) are not referenced by the on-line docs and don't need comments. Tables built for online only include public symbols. - Better links for constructors, destructors, operators - Fixed some minor public interfaces - Removed _const crutch on operators - Keep includes inside 100 columns TBR=reed@google.com Docs-Preview: https://skia.org/?cl=171900 Bug: skia: Change-Id: I93b229c6625d800604671e05b82a14c06cb906d2 Reviewed-on: https://skia-review.googlesource.com/c/171900 Reviewed-by: Cary Clark <caryclark@skia.org> Commit-Queue: Cary Clark <caryclark@skia.org>
5.9 KiB
SkBlendMode Overview
Describes how destination pixel is replaced with a combination of itself and source pixel. Blend_Mode may use source, destination, or both. Blend_Mode may operate on each Color component independently, or may allow all source pixel components to contribute to one destination pixel component.
Blend_Mode does not use adjacent pixels to determine the outcome.
Blend_Mode uses source and read destination Alpha to determine written destination Alpha; both source and destination Alpha may also affect written destination Color components.
Regardless of how Alpha is encoded in source and destination pixel, nearly all Color_Types treat it as ranging from zero to one. And, nearly all Blend_Mode algorithms limit the output so that all results are also zero to one.
Two exceptions are SkBlendMode::kPlus and kRGBA_F16_SkColorType.
SkBlendMode::kPlus permits computing Alpha and Color component values larger than one. For Color_Types other than kRGBA_F16_SkColorType, resulting Alpha and component values are clamped to one.
kRGBA_F16_SkColorType permits values outside the zero to one range. It is up to the client to ensure that the result is within the range of zero to one, and therefore well-defined.
Compositing Digital Images describes Porter_Duff modes SkBlendMode::kClear through SkBlendMode::kXor.
Drawing a bitmap with transparency using Porter_Duff compositing is free to clear the destination.
Draw geometry with transparency using Porter_Duff compositing does not combine transparent source pixels, leaving the destination outside the geometry untouched.
Modes SkBlendMode::kPlus and SkBlendMode::kScreen use simple arithmetic to lighten or darken the destination. Modes SkBlendMode::kOverlay through SkBlendMode::kMultiply use more complicated algorithms to lighten or darken; sometimes one mode does both, as described by Blend Modes .
SkBlendMode::kModulate is a mashup of SkBlendMode::kSrcATop and SkBlendMode::kMultiply. It multiplies all components, including Alpha; unlike SkBlendMode::kMultiply, if either source or destination is transparent, result is transparent. SkBlendMode::kModulate uses Premultiplied values to compute the product; SkBlendMode::kMultiply uses Unpremultiplied values to compute the product.
Modes SkBlendMode::kHue, SkBlendMode::kSaturation, SkBlendMode::kColor, and SkBlendMode::kLuminosity convert source and destination pixels using all components color information, using non-separable blend modes .
