[cairo] status of dashed curve_to ?

[John Ellson]

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
>spline.
>  
>

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
be sufficient?


John