Cary Clark | 61313f3 | 2018-10-08 14:57:48 -0400 | [diff] [blame^] | 1 | #Topic Blend_Mode_Overview |
| 2 | |
| 3 | Describes how destination pixel is replaced with a combination of itself and |
| 4 | source pixel. Blend_Mode may use source, destination, or both. Blend_Mode may |
| 5 | operate on each Color component independently, or may allow all source pixel |
| 6 | components to contribute to one destination pixel component. |
| 7 | |
| 8 | Blend_Mode does not use adjacent pixels to determine the outcome. |
| 9 | |
| 10 | Blend_Mode uses source and read destination Alpha to determine written |
| 11 | destination Alpha; both source and destination Alpha may also affect written |
| 12 | destination Color components. |
| 13 | |
| 14 | Regardless of how Alpha is encoded in source and destination pixel, nearly all |
| 15 | Color_Types treat it as ranging from zero to one. And, nearly all Blend_Mode |
| 16 | algorithms limit the output so that all results are also zero to one. |
| 17 | |
| 18 | Two exceptions are SkBlendMode::kPlus and kRGBA_F16_SkColorType. |
| 19 | |
| 20 | SkBlendMode::kPlus permits computing Alpha and Color component values larger |
| 21 | than one. For Color_Types other than kRGBA_F16_SkColorType, resulting Alpha |
| 22 | and component values are clamped to one. |
| 23 | |
| 24 | kRGBA_F16_SkColorType permits values outside the zero to one range. It is up |
| 25 | to the client to ensure that the result is within the range of zero to one, |
| 26 | and therefore well-defined. |
| 27 | |
| 28 | #Subtopic Porter_Duff |
| 29 | #Alias Porter_Duff ## |
| 30 | #Line # classic color blend algorithms ## |
| 31 | |
| 32 | #A Compositing Digital Images # https://graphics.pixar.com/library/Compositing/paper.pdf ## |
| 33 | describes Porter_Duff modes SkBlendMode::kClear through SkBlendMode::kXor. |
| 34 | |
| 35 | Drawing a bitmap with transparency using Porter_Duff compositing is free to clear |
| 36 | the destination. |
| 37 | |
| 38 | #Illustration 1 |
| 39 | |
| 40 | Draw geometry with transparency using Porter_Duff compositing does not combine |
| 41 | transparent source pixels, leaving the destination outside the geometry untouched. |
| 42 | |
| 43 | #Illustration 2 |
| 44 | |
| 45 | ## |
| 46 | |
| 47 | #Subtopic Lighten_Darken |
| 48 | #Line # color blends to lighten or darken result ## |
| 49 | |
| 50 | Modes SkBlendMode::kPlus and SkBlendMode::kScreen use |
| 51 | simple arithmetic to lighten or darken the destination. Modes |
| 52 | SkBlendMode::kOverlay through SkBlendMode::kMultiply use more complicated |
| 53 | algorithms to lighten or darken; sometimes one mode does both, as described by |
| 54 | #A Blend Modes # https://en.wikipedia.org/wiki/Blend_modes ## |
| 55 | . |
| 56 | |
| 57 | #Illustration |
| 58 | |
| 59 | ## |
| 60 | |
| 61 | #Subtopic Modulate_Blend |
| 62 | #Line # multiply color components ## |
| 63 | |
| 64 | SkBlendMode::kModulate is a mashup of SkBlendMode::kSrcATop and SkBlendMode::kMultiply. |
| 65 | It multiplies all components, including Alpha; unlike SkBlendMode::kMultiply, if either |
| 66 | source or destination is transparent, result is transparent. SkBlendMode::kModulate |
| 67 | uses Premultiplied values to compute the product; SkBlendMode::kMultiply uses Unpremultiplied |
| 68 | values to compute the product. |
| 69 | |
| 70 | #Illustration |
| 71 | |
| 72 | ## |
| 73 | |
| 74 | #Subtopic Color_Blends |
| 75 | #Line # non-separable blend modes ## |
| 76 | |
| 77 | Modes SkBlendMode::kHue, SkBlendMode::kSaturation, SkBlendMode::kColor, and |
| 78 | SkBlendMode::kLuminosity convert source and destination pixels using all |
| 79 | components color information, using |
| 80 | ###$ |
| 81 | $A non-separable blend modes $ https://www.w3.org/TR/compositing-1/#blendingnonseparable $$ |
| 82 | $$$# |
| 83 | . |
| 84 | |
| 85 | #Illustration |
| 86 | |
| 87 | ## |
| 88 | |
| 89 | #Topic Blend_Mode_Overview ## |