[cairo] status of dashed curve_to ?
ellson at research.att.com
Tue May 31 11:48:59 PDT 2005
Carl Worth wrote:
>>Isn't dashing a spline like dashing a polyline with very short segments,
>>or are there deeper issues?
>It's not exactly the same. It differs in the same way that stroking a
>spline is different than stroking a polyline. Simply converting the
>spline to a piece-wise linear approximation and stroking that won't
>guarantee an accurate result. But we could actually make that work by
>adding round joins to the vertex within the approximation of the
That seems reasonable, and round joins for polylines are already
supported in _cairo_stroker_join().
>The other thing that currently makes the line and spline
>implementation look very different is that the code currently emits
>trapezoids on-the-fly while stroking. An alternate approach would be
>to compute the path of the stroke boundary and then to just fill
>that. This alternate approach will be "less efficient"[*], (though
>tessellation time isn't yet our performance bottleneck), but it will
>also give correct results for self-intersecting paths, (which the
>incremental trapezoid-generation does not).
Are self-intersecting polylines dealt with now? Couldn't we just deal
with that case and
reuse the same code for curves?
>So, it might make sense to re-work that part first. With that in
>place, the dashing could just fall out and no new dashing code would
>really be needed.
Right, because it is already supported for polylines.
So I guess I'm asking if _cairo_stroker_curve_to() couldn't just convert
the bezier segment to a sequence
of _cairo_stroker_line_to() with round[*] joins (and similarly for the
dashed versions) and that should be it?
[*] At the tolerance level of straight line segments approximating the
bezier, why wouldn't miter joins
More information about the cairo