61313f38e1
First cut at splitting bookmaker documentation into reference and overview. Reference starts with a hyperlinked index, generated from a public include. This moves towards typing once, minimizing the information duplicated in the .h file and the .bmh file. TBR=caryclark@google.com Docs-Preview: https://skia.org/?cl=154630 Change-Id: I836622db9b1786bd28c0bce2536cd3caef6e5a32 Reviewed-on: https://skia-review.googlesource.com/c/154630 Commit-Queue: Cary Clark <caryclark@skia.org> Auto-Submit: Cary Clark <caryclark@skia.org> Reviewed-by: Cary Clark <caryclark@skia.org>
90 lines
3.0 KiB
Plaintext
90 lines
3.0 KiB
Plaintext
#Topic Blend_Mode_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.
|
|
|
|
#Subtopic Porter_Duff
|
|
#Alias Porter_Duff ##
|
|
#Line # classic color blend algorithms ##
|
|
|
|
#A Compositing Digital Images # https://graphics.pixar.com/library/Compositing/paper.pdf ##
|
|
describes Porter_Duff modes SkBlendMode::kClear through SkBlendMode::kXor.
|
|
|
|
Drawing a bitmap with transparency using Porter_Duff compositing is free to clear
|
|
the destination.
|
|
|
|
#Illustration 1
|
|
|
|
Draw geometry with transparency using Porter_Duff compositing does not combine
|
|
transparent source pixels, leaving the destination outside the geometry untouched.
|
|
|
|
#Illustration 2
|
|
|
|
##
|
|
|
|
#Subtopic Lighten_Darken
|
|
#Line # color blends to lighten or darken result ##
|
|
|
|
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
|
|
#A Blend Modes # https://en.wikipedia.org/wiki/Blend_modes ##
|
|
.
|
|
|
|
#Illustration
|
|
|
|
##
|
|
|
|
#Subtopic Modulate_Blend
|
|
#Line # multiply color components ##
|
|
|
|
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.
|
|
|
|
#Illustration
|
|
|
|
##
|
|
|
|
#Subtopic Color_Blends
|
|
#Line # non-separable blend modes ##
|
|
|
|
Modes SkBlendMode::kHue, SkBlendMode::kSaturation, SkBlendMode::kColor, and
|
|
SkBlendMode::kLuminosity convert source and destination pixels using all
|
|
components color information, using
|
|
###$
|
|
$A non-separable blend modes $ https://www.w3.org/TR/compositing-1/#blendingnonseparable $$
|
|
$$$#
|
|
.
|
|
|
|
#Illustration
|
|
|
|
##
|
|
|
|
#Topic Blend_Mode_Overview ##
|