[timzifer]

Problem

Translucent fills and strokes rendered through the GPU stencil path are darker and grayer than the CPU output. Opaque colors are correct, as are translucent SDF shapes and convex fills, which makes the difference depend on the geometry being drawn.

GPURenderContext.preTessellateFill stores premultiplied RGBA in StencilPathCommand.Color. buildStencilResourcesBatch then puts those values into a straight-alpha gg.RGBA, and makeCoverUniform multiplies RGB by alpha again. Over a background B, the result is alpha² * color + (1 - alpha) * B instead of alpha * color + (1 - alpha) * B.

This affects concave paths, multiple subpaths in one fill, and strokes whose expanded outline takes the stencil path.

Fix

Keep the command's premultiplied [4]float32 color through createRenderBuffers and makeCoverUniform, writing it unchanged to the cover shader's uniform. The standalone StencilRenderer.RenderPath entry point still accepts straight alpha and now premultiplies once before calling the shared buffer builder.

No public API change. The shader, blend state, and SDF/convex paths are unchanged.

Minimal example

With github.com/gogpu/gg/gpu and a hardware backend imported:

c := gg.NewContext(100, 100)
c.ClearWithColor(gg.White)
c.SetRGBA(0, 114.0/255, 178.0/255, 89.0/255)
c.MoveTo(10, 10)
c.LineTo(90, 10)
c.LineTo(60, 50) // inward corner: stencil-then-cover
c.LineTo(90, 90)
c.LineTo(10, 90)
c.ClosePath()
_ = c.Fill()
_ = c.FlushGPU()
// Interior RGB: before (166,180,188), after (166,206,228).
// CPU reference: (166,205,228); the remaining byte is rounding.

repro-alpha/main.go renders SDF rectangles, convex fills, concave fills and disjoint subpaths at five alpha values. Each run also renders a CPU reference. Opaque shapes and the first two rows are controls.

GPU, v0.52.5	GPU, this PR	CPU reference

In the wild: figure

We found this in figure, a grammar-of-graphics plotting library for Go that renders through gg. Its violin plots use 35% fill opacity. Switching to the GPU made the interiors gray while the opaque outlines and legend colors stayed correct.

repro-alpha-violin/main.go renders the same deterministic gallery example on both tiers:

GPU, v0.52.5	GPU, this PR	CPU reference

The CPU reference PNGs are byte-identical before and after the change. Reproduction instructions and measured pixels are on the evidence branch; image files and examples are outside this PR's code diff.

Tests

• TestStencilCoverPreservesPremultipliedColor follows fill and stroke paint through tessellation to the cover uniform at alpha 0, 0.125, 0.35, 0.5, 0.75 and 1. It uses different fill and stroke colors and needs no GPU. Reintroducing the second multiplication makes all eight translucent cases fail.
• TestMakeCoverUniform now checks the explicit premultiplied input contract.
• go test -race ./..., go build ./..., and golangci-lint run --timeout=5m pass on the isolated PR branch (Windows amd64, Go 1.25.3).
• The two examples were also rendered on a working GPU. At alpha 89/255, the previously darkened interior channels now differ from the CPU by at most one byte.

[kolkov]

Checked the color path: the stencil command's color is already premultiplied, and makeCoverUniform multiplied it again. Keeping the [4]float32 through to the uniform fixes it without touching the shader or blend state. This also merges cleanly with the fixes queued for the next release, which touch the same two files.

[kolkov]

A follow-up from testing the v0.52.6 release: examples/clip_demo shows exactly the bug you fixed here. Its 15% white orbit ring is invisible on the dark background and draws as a dark line across every circle it crosses, which is the double premultiply on the stencil path. It looks the same on v0.52.5, so it's been there a while.

v0.52.6 is out without this one, only because CI never ran on the branch. A push to start CI is all it needs, and I'd like it in v0.52.7.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kolkov]

Thanks, this is the right fix and the analysis is right. preTessellateFill/preTessellateStroke store premultiplied RGBA in StencilPathCommand.Color, and makeCoverUniform multiplied by alpha a second time, so a translucent stencil fill or stroke came out as alpha²·color + (1−alpha)·B. Opaque colours were unaffected, which is why it depended on the geometry.

I checked both callers of createRenderBuffers: the batch path already carries a premultiplied [4]float32, and RenderPath takes straight alpha and now premultiplies once before handing over. Both correct, and no other caller exists.

The test walks the colour from the paint through tessellation to the cover uniform, for fill and stroke at six alphas, and it fails on main. That is the coverage this needed.

Merging for v0.52.7.