Clip path fill bleed

[rgsouthall]

Hi Samuel.
I have noticed that when using a clippath on a shape that bisects the shape's stroke there is some colour bleed of the shape fill colour outside the clip, when I would expect the stroke colour to take precedence. When there is no clip-path, behaviour is as expected: only the stroke colour blends into the transparent background. The two svg files below show this when converted to png with svg2png. The difference is subtle, and you may need to convert at a high resolution to see it, but when I send the png data to Blender it can be quite noticeable in certain cases.
Cheers
Ryan

[sammycage]

Thanks for the report, Ryan. I will definitely look into it.

[sammycage]

Hi 👋,

After digging into this, the behavior matches how the current stroke pipeline is implemented in PlutoVG.

In plutovg_canvas_stroke_preserve, the stroke is first rasterized into an antialiased span buffer (fill_spans). When clipping is enabled, those already-antialiased stroke spans are then intersected with the clip spans via plutovg_span_buffer_intersect, which effectively multiplies the stroke coverage with the clip coverage. If the clip edge bisects the stroke, this results in pixels with very low alpha at the boundary.

Because the clip is applied after stroke rasterization, the intersection of two antialiased edges can produce subtle artifacts, which show up as fill-color bleed when the result is blended. Without a clip-path, the stroke spans are blended directly, so only a single antialiased edge is involved and the issue does not appear.

I tried converting the clip path to a rectangular clip where possible, since axis-aligned rectangular clips avoid antialiasing at the clip boundary and usually eliminate the artifact. This works in many cases, but it is not always reliable when the coordinate values are very small, as rounding and precision errors can reintroduce subtle artifacts.

So this looks like a side effect of applying antialiased clip spans to antialiased stroke spans, rather than an intentional stroke vs fill precedence issue.

[sammycage]

Quick question on impact: on my end the artifact is extremely subtle. I have to zoom in to around 1000% at a resolution of roughly 1449 × 1024 before I can reliably notice it.

In Blender, does this show up as a visually disturbing artifact in normal workflows or final renders, or is it more of an edge-case issue that only becomes apparent under heavy zoom or specific compositing conditions? I just want to understand whether this is effectively a show-stopper for your use case, or something that is acceptable given the current trade-offs.

[rgsouthall]

Hi.
It can be quite noticeable, especially when it's a white fill and black stroke, with a low DPI or with a high DPI displayed zoomed in, but I have altered my svg2buff code to square the float of pixel alpha when it's below 1. Slows things down a bit, but not by much and that makes the issue much less noticeable. If it's not a simple, desirable change then don't worry.
Cheers
Ryan

[rgsouthall]

Forget to say I noticed it's much more noticeable in linear colour space, which Blender assumes pixel data is in and displays it as such. In sRGB colour space it is much less noticeable (because of the approximate square of pixel float values), so this is probably rather an edge-case in LunaSVG terms.
Cheers
Ryan