Currently going down a rabbit hole of:

• "Linear RGB" vs "sRGB (gamma)"
• "Premultiplied Alpha" vs "Unpremultiplied Alpha"
• "Alpha" vs "Coverage"
• "Blending in linear RGB space" vs "Blending in sRGB space"
• ...

In the meantime I found an even more basic repro: Just set the the circle fill and the background color to the same one, works better with brighter ones:

Another update: My main suspect now is linear texture filtering in combination with sRGBA textures and premultiplied alpha.

A couple of observations:

1. In this part of the Tessellator, circles are rendered using rectangles UV mapped to the closest (in size) circle from the texture atlas. To achieve the exact requested circle size, the rectangle is then scaled as necessary. If I hardcode this scale such that texture atlas pixels map exactly to final rendered pixels, the artifacts disappear (because no texture interpolation is necessary anymore).
   

   egui/crates/epaint/src/tessellator.rs

   Lines 1509 to 1531 in eb7ca72

   	if self.options.prerasterized_discs && fill != Color32::TRANSPARENT {
   	let radius_px = radius * self.pixels_per_point;
   	// strike the right balance between some circles becoming too blurry, and some too sharp.
   	let cutoff_radius = radius_px * 2.0_f32.powf(0.25);
   	// Find the right disc radius for a crisp edge:
   	// TODO(emilk): perhaps we can do something faster than this linear search.
   	for disc in &self.prepared_discs {
   	if cutoff_radius <= disc.r {
   	let side = radius_px * disc.w / (self.pixels_per_point * disc.r);
   	let rect = Rect::from_center_size(center, Vec2::splat(side));
   	out.add_rect_with_uv(rect, disc.uv, fill);
   	if stroke.is_empty() {
   	return; // we are done
   	} else {
   	// we still need to do the stroke
   	fill = Color32::TRANSPARENT; // don't fill again below
   	break;
   	}
   	}
   	}
   	}

2. If I force texture interpolation to NEAREST instead of LINEAR (requires modifications across the renderer) the artifacts disappear.
3. Interpolation of sRGB textures is actually not very well specified: Implementations can choose if the "srgb to linear" conversion happens before or after the interpolation. I couldn't find anything about it in the WebGPU spec, but here is the relevant excerpt from the OpenGL Spec:

Interpolation of sRGB textures is actually not very well specified: Implementations can choose if the "srgb to linear" conversion happens before or after the interpolation. [...]

It must happen before unless you upsample. If you downsample a non-linear texture you introduce artifacts. Same rules as with alpha apply.

TLDR; you can't correctly blend/mix samples that have a burned-in curve of some sort (gamma, whatever).

Lastly, when you filter a pre-multiplied non-linear texture it gets worse at the edges (because the alpha exacerbates the error, the more transparent the sample, the more error; see also #5771).

Oh I completely agree, which is why I'm so surprised that the spec can be that vague. That being said, I'm not convinced that the incorrect interpolation order is what is happening here.

Oh I completely agree, which is why I'm so surprised that the spec can be that vague. That being said, I'm not convinced that the incorrect interpolation order is what is happening here.

The reason is most likely that the spec was written by people who didn't know what they're talking about. At the risk of sounding like an old curmudgeon: as the years go by the quality of specs I'm confronted with in my line of work has steadily declined. Shockingly so if you compare with specs from the 80's or 90's.

The best specs are usually those written by a single individual who were at the helm of whatever tech the spec describes.
And specs of tech designed by committee (Khronos group, W3C, etc.) tend to be the worst. Both in what they contain, how they're written and how many important things they omit. 😉