Description
Graphite’s clipping-mask rendering pipeline treats masks exclusively as alpha masks.
SVG masks can instead use luminance, where the rendered color brightness determines
visibility.
This causes imported luminance masks to render incorrectly even after support for
reading usvg::Group::mask() is implemented.
Dependency
This issue depends on adding SVG mask importing through usvg::Group::mask().
Until that importer support exists, the reproduction also fails because the entire mask
is discarded. Once mask importing is connected, this issue isolates the remaining
alpha-versus-luminance rendering failure.
Reproduction
Import HameronsDocs/svg-luminance-mask-debug.svg.
The fixture contains:
- One solid blue rectangle.
- An explicitly declared
mask-type="luminance".
- An opaque white rectangle that reveals the artwork.
- An opaque black circle that creates a transparent hole.
- No gradients, transforms, strokes, clip paths, filters, or fill-rule dependencies.
<svg xmlns="http://www.w3.org/2000/svg" width="128" height="128" viewBox="0 0 128 128">
<defs>
<mask id="luminance-hole" mask-type="luminance"
maskUnits="userSpaceOnUse" x="0" y="0" width="128" height="128">
<rect width="128" height="128" fill="white" />
<circle cx="64" cy="64" r="32" fill="black" />
</mask>
</defs>
<rect width="128" height="128" fill="#2563eb"
mask="url(#luminance-hole)" />
</svg>
Expected behavior
The SVG imports as a blue square with a transparent circular hole in its center.
Under luminance-mask semantics:
- White produces full visibility.
- Black produces full transparency.
- Gray or colored content produces partial visibility based on luminance and alpha.
Actual behavior
Graphite’s alpha-only mask behavior treats both the white rectangle and black circle as
fully opaque because both have alpha 1.
The resulting artwork is therefore a solid blue square without a transparent hole.
Root cause
The resolved usvg::Mask preserves its semantic mode through usvg::Mask::kind(), which
distinguishes MaskType::Luminance from MaskType::Alpha.
Graphite does not carry that distinction through its document graph or renderers:
- The SVG renderer emits generated masks with mask-type="alpha".
- The Vello renderer composites clipping masks using source alpha through SrcIn.
- Mask colors are therefore ignored when calculating visibility.
- Graphite’s internal MaskType currently distinguishes Clip from Mask, not luminance
from alpha.
Simply importing the SVG mask geometry through the existing clipping-mask mechanism is
insufficient because opaque black and opaque white produce identical alpha values.
Suggested scope
Preserve the resolved SVG mask mode and support luminance-to-alpha conversion
consistently across Graphite’s SVG and Vello renderers.
This should remain separate from the issue that connects usvg::Group::mask() to the
importer because it requires renderer and document-attribute support rather than only
importer wiring.
The SVG specification defines luminance as the initial value for elements, so
masks without an explicit mask-type must also use luminance semantics.
Reference: https://www.w3.org/TR/css-masking-1/#the-mask-type
Acceptance criteria
- The isolated fixture renders as a blue square with a transparent circular hole.
- Explicit mask-type="alpha" masks retain existing alpha behavior.
- Explicit mask-type="luminance" masks use color luminance multiplied by source alpha.
- Masks without mask-type default to luminance.
- Black, white, gray, colored, and partially transparent mask content behave correctly.
- SVG and Vello rendering produce equivalent results.
- SVG output preserves or emits the correct mask type.
- Regression tests cover both alpha and luminance masks.
Description
Graphite’s clipping-mask rendering pipeline treats masks exclusively as alpha masks.
SVG masks can instead use luminance, where the rendered color brightness determines
visibility.
This causes imported luminance masks to render incorrectly even after support for
reading
usvg::Group::mask()is implemented.Dependency
This issue depends on adding SVG mask importing through
usvg::Group::mask().Until that importer support exists, the reproduction also fails because the entire mask
is discarded. Once mask importing is connected, this issue isolates the remaining
alpha-versus-luminance rendering failure.
Reproduction
Import
HameronsDocs/svg-luminance-mask-debug.svg.The fixture contains:
mask-type="luminance".Expected behavior
The SVG imports as a blue square with a transparent circular hole in its center.
Under luminance-mask semantics:
Actual behavior
Graphite’s alpha-only mask behavior treats both the white rectangle and black circle as
fully opaque because both have alpha 1.
The resulting artwork is therefore a solid blue square without a transparent hole.
Root cause
The resolved usvg::Mask preserves its semantic mode through usvg::Mask::kind(), which
distinguishes MaskType::Luminance from MaskType::Alpha.
Graphite does not carry that distinction through its document graph or renderers:
from alpha.
Simply importing the SVG mask geometry through the existing clipping-mask mechanism is
insufficient because opaque black and opaque white produce identical alpha values.
Suggested scope
Preserve the resolved SVG mask mode and support luminance-to-alpha conversion
consistently across Graphite’s SVG and Vello renderers.
This should remain separate from the issue that connects usvg::Group::mask() to the
importer because it requires renderer and document-attribute support rather than only
importer wiring.
The SVG specification defines luminance as the initial value for elements, so
masks without an explicit mask-type must also use luminance semantics.
Reference: https://www.w3.org/TR/css-masking-1/#the-mask-type
Acceptance criteria