Hi, I'm looking at using Vello to render GIS vector data — polylines, polygons, administrative boundaries, that sort of thing. The vast majority of segments in this kind of data are plain straight lines.
While profiling, I noticed that even a PATH_TAG_LINETO goes through degree-raising to a cubic Bézier and then through the full flatten_euler pipeline, including cubic_from_points_derivs, the Euler spiral parameter computation, and the iteration loop. For strokes with an offset it happens twice, once per offset curve. Because the result is a collinear cubic, the Euler machinery converges quickly, but the intermediate computations still run on every single segment.
What do you think about adding a small fast path in flatten.wgsl main(), gated on seg_type == PATH_TAG_LINETO, that skips degree-raising and flatten_euler entirely? For fills it could call output_line directly with the transformed endpoints. For strokes the two offset lines are analytically trivial from the normal, and caps/joins are already handled separately.
This wouldn't touch curves at all — only LINETO. But for workloads like GIS where straight segments dominate, it would cut per-segment flatten time down to a couple of writes.
Curious if you see any pitfalls, or if this is something worth exploring.
Hi, I'm looking at using Vello to render GIS vector data — polylines, polygons, administrative boundaries, that sort of thing. The vast majority of segments in this kind of data are plain straight lines.
While profiling, I noticed that even a PATH_TAG_LINETO goes through degree-raising to a cubic Bézier and then through the full flatten_euler pipeline, including cubic_from_points_derivs, the Euler spiral parameter computation, and the iteration loop. For strokes with an offset it happens twice, once per offset curve. Because the result is a collinear cubic, the Euler machinery converges quickly, but the intermediate computations still run on every single segment.
What do you think about adding a small fast path in flatten.wgsl main(), gated on seg_type == PATH_TAG_LINETO, that skips degree-raising and flatten_euler entirely? For fills it could call output_line directly with the transformed endpoints. For strokes the two offset lines are analytically trivial from the normal, and caps/joins are already handled separately.
This wouldn't touch curves at all — only LINETO. But for workloads like GIS where straight segments dominate, it would cut per-segment flatten time down to a couple of writes.
Curious if you see any pitfalls, or if this is something worth exploring.