[cairo] status of dashed curve_to ?

[Carl Worth]

On Tue, 31 May 2005 11:12:41 -0400, John Ellson wrote:
> Can I ask about the status of dashed curves in Cairo?

Of course. :-)

> This is a blocker for us in Graphviz at the moment.

I'm really surprised this limitation has been around so long without
more complaints, (though, notably, dia also noticed it).

> It looks like there needs to be an implementation of 
> _cairo_stroker_curve_to_dashed() in cairo-path-stroke.c ?

Yes, something like that. Keith claims it should be fairly
straightforward. I've just never convinced him to add dashed splines
since he did the original work for dashed lines quite long ago.

> Is someone already working on this?

Not that I'm aware of.

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

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

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.

I even wrote some code once to replace the incremental trapezoid
generation with compute-stroke-boundary-path-then-fill, and I believe
I didn't commit it because it put increased stress on our tessellation
code. At this point, I could use the extra push to finally replace our
pathetic tessellation function, so I'd be glad to see this land.

Any help with any of this would be quite appreciated. I can provide
more detailed guidance wherever necessary.

-Carl

[*] If there is any measurable performance loss, it might be possible
to detect non-self-intersecting paths and add back incremental
stroking there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050531/018117fd/attachment.pgp