-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendering issue when clipping and stroking the same path #616
Comments
Hm, that definitely looks like a rendering issue. Is there any chance you could make a minimal repro? |
Sure thing! I wasn't able to quickly repro the big black rectangle, but hopefully that's the same problem. It looks like it only happens at certain coordinates, which is why the rectangle is at (60., 10.) it doesn't happen at 61, for example. Swap this function in to the "simple" example in the vello repo: fn add_shapes_to_scene(scene: &mut Scene) {
let rect = RoundedRect::new(60.0, 10.0, 160.0, 100.0, 10.0);
let stroke = Stroke::new(2.0);
let fill = vello::peniko::Fill::NonZero;
let mask_blend = vello::peniko::BlendMode::new(vello::peniko::Mix::Normal, vello::peniko::Compose::SrcOver);
scene.push_layer(mask_blend, 1.0, Affine::IDENTITY, &rect);
scene.stroke(&stroke, Affine::IDENTITY, Color::BLACK, None, &rect);
scene.pop_layer();
} |
So it turns out that this has nothing to do with clipping layers. The following code also exhibits the issue: let rect = RoundedRect::new(60.0, 10.0, 160.0, 100.0, 10.0);
let stroke = Stroke::new(2.0);
scene.stroke(&stroke, Affine::IDENTITY, Color::WHITE, None, &rect); |
I can reproduce. Some triage:
|
Based on Daniel's investigation, this seems most likely to be a watertightness issue in the flatten stage, possibly related to fastmath (another issue that implicates fastmath is #581, so we should probably look at these together). A good next step would be to examine the output of the flatten stage (ie the line soup buffer). We made some effort to make joins watertight, but it's very easy to image we missed something. |
At subpath end, the last path segment is encoded with the end point chosen so that the vector from the current point to the end point is the tangent, ie the same vector as cubic_start_tangent applied to the first segment in the subpath. In those cases, compute the tangent by subtracting those two points, rather than cubic_start_tangent applied to the line. These are mathematically identical, but may give different results because of roundoff. There are two cases: an open subpath, in which case the case is applied to the tangent at draw_start_cap, or a closed subpath, where the logic is in the tangent calculation in read_neighboring_segment. Both GPU and CPU shaders are updated. It hasn't been carefully validated. Hopefully fixes #616 and #650.
This was contributed in linebender#616 (comment) Co-Authored-By: TimTom <[email protected]>
This is a test created from #616 (comment). This was fixed in #695. The version which fails looked like: ![half circle with an intruding line.](https://github.com/user-attachments/assets/9b567912-2ad3-4d11-96cd-6db43dd64b09) --------- Co-authored-by: TimTom <[email protected]>
I'm trying to render a simple UI, and I'm using the same path to clip the contents of each button as well as stroke the border, but I'm getting some artifacts in the corners of some of the buttons. Is this a known issue?
The text was updated successfully, but these errors were encountered: