Odd Dashed Strokes

[corey....@gmail.com]

With 1 or 2 pixel corner radii on rounded corners we are seeing these artifacts on dashed and dotted strokes.

Any idea why and if it can be fixed?

https://fiddle.skia.org/c/6d743ce24ff0f4d5403fe725a044a44c

Thanks.

[corey....@gmail.com]

Forgot to mention...what's up with the GPU code path these days, why is the dash pattern in completely different locations?

[aron Leonard]

Hi Corey,

Thanks for reaching out! I hope you're doing well. I see you had a question about the GPU code path and the dash pattern. I'm not entirely sure about the answer, but I'd be happy to look into it for you. Would you like me to get back to you with more information once I've figured it out?

Best,

Aron

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/b4084bab-7dca-42c2-9a9e-d446dc184d72n%40googlegroups.com.

[corey....@gmail.com]

Oh sure just post a response to this list for the benefit of others if you find clues, much obliged.

The dash artifacts around the corners are happening on both cpu and gpu, I just noticed that as an aside, the pattern seems to be starting in a completely different point on GPU.

-C

[Michael Ludwig]

Thanks for the bug reports Corey, there are two separate things going on here. 

The easy one first, some time ago while I was refactoring our GrStyledShape class, an explicit round rect switched to defaulting its dashing from index 0. SkPaths created from a round rect (e.g. SkPath::addRRect, etc.) have been historically defined to use index 6 or 7 depending on the direction of the verbs. The CPU backend always just converts shapes to paths so remained consistent. I have a fix for the starting position of the dashes here: https://skia-review.googlesource.com/c/skia/+/698218

The second has to do with numerical stability, tiny path sections, and winding rules of strokes vs. fillls. See https://bugs.chromium.org/p/skia/issues/detail?id=13030 for a bit more context. Basically, when we do a perpendicular sweep line to form the stroke, and the path has high curvature relative in a small area relative to the stroke width, the sweep line pivots about itself.  For a rounded rect with a 1px corner, it's doing a 90 degree turn very quickly and creates the quarter circle on one quadrant and a swoop cutout on the other. Even if you changed the verb/point construction of the path to get rid of the swoop, the stroking would never cover a quarter circle.  This shows up in the dashing because the on interval happens to end right at the end of the rounded corner.

Skia doesn't do any munging of dashing intervals to avoid this, and it applies dashing in the original coordinate space and as a separate action from the stroking itself. Without either of those two pieces, it's hard for it to identify parts of the original path and the dashing pattern that would create problematic strokes.

For a case like this, the best workaround I have is to detect that your corners will project to a very small shape relative to the stroke width (in this case I believe it's if the corner radii are less than half the stroke width), and switch to a rectangle with round joins, or clamp the corner radii.