Closed jrmuizel closed 2 years ago
Yes, I've planned to expose PathStroker
initially but couldn't settle on the API and simply hid it.
And yes, I did thought about splitting tiny-skia into smaller crates. It does too much for my taste. But before separating the PathStroker
, we first have to separate the Path
itself, meaning all the geometry primitives too.
I guess I can create something like tiny-skia-path
or tiny-skia-geom
, which will include all the geometry primitives + stroker + dasher. But there is also a lot of math code related to path rendering, not sure where it should live.
Thanks! Is it ready to be published?
Hopefully this weekends.
Done: https://crates.io/crates/tiny-skia-path
I plan to eventually remove all geometry primitives out of it too. But it will take some time.
Hi, Just wondering if the code should deal with self intersections, or is this not required for the main package. Would the black lines be the expected stroke for the red line? Thanks.
Yes, this is by design. This is how Skia works and I don't think there is an easy way to do otherwise. CGPath from CoreGraphics will produce a similar result (i.e. with overlapping segments). This is just how stroking generally implemented. You're supposed to simply fill the produced path.
What you want is probably inset/outset operations, but they have a totally different implementation. And no, there are no plans on implementing them. tiny-skia stroker alone is already 3000 LOC.
Thanks. Assumed that might be the cases, just want to double check.
resvg and the associated projects are superb. Thanks for the epic effort.
Thanks!
The path stroking code in tiny-skia would be useful for a variety of other 2d graphics libraries. Would you be interested in having it in a standalone crate? If not it would still be useful to expose PathStroker.