Vixen
dd8b0a81
csharp
public static class UiBlend

CSS Compositing 1 § 5's blend functions, over premultiplied colour.

Read the guide page for this →

Remarks

⚠ A blend is the one group-wide effect that is a function of both operands, and that is what separates it from every other field on UiLayer. Fading a surface in, blurring it, tinting it by a matrix or multiplying its coverage by a mask are all functions of the surface alone, so an executor can produce the composite's colour without ever looking at what it is landing on. A blend cannot: it needs the backdrop. SoftwareUiRasterizer gets that for free, because it owns the destination buffer.

⚠ The whole feature is nevertheless expressible as a change of source colour followed by an ordinary source-over — which is the arrangement CSS itself specifies in § 5.1, and the reason no executor needs a second blend state. Apply returns the premultiplied colour to composite normally, so the one line in a rasteriser that reads the destination is the only line that changes. On a device the same identity says the backdrop may arrive as a texture rather than as a framebuffer read — the capture UiRenderer.Capture already performs for backdrop-filter is exactly the picture this function's backdrop argument wants.

⚠ The arithmetic is done on the values the surface holds, which in this engine are linear, and CSS blends in the device's colour space, which in a browser is sRGB. That is a stated divergence rather than an oversight. multiply of two mid-greys is perceptibly darker in linear than in sRGB. Converting here would mean encoding and decoding a transfer function per pixel in the composite, on both executors, and writing back into an attachment that is linear — which is a colour-management decision for the whole interface rather than for this function. Recorded in docs/guide/ui/compositing.md.

Methods (2)

Used by (3)

  • MixBlendModeLuminanceTestsVixen.Ui.Controls.Tests
  • MixBlendModeTestsVixen.Ui.Controls.Tests
  • SoftwareUiRasterizerVixen.Ui.Testing