[cairo] Questions and optimizations in cairo-arc

[Behdad Esfahbod]

On Tue, 26 Jul 2005, Carl Worth wrote:

> On Tue, 26 Jul 2005 06:42:27 -0400 (EDT), Behdad Esfahbod wrote:
> > I was looking at the cairo-arc.c source code and performed some
> > trivial optimizations.  Patch attached.
>
> Have you done any benchmarking to justify these changes? The inlining
> of _cairo_arc_segment does make the code harder to read so it's not
> something I want to do without justification.

Ok, will check, but I was not easy with computing h for every
piece and duplicated sin & cos computation.


> > /* XXX: NYI
> > void
> > cairo_arc_to (cairo_t *cr,
> >               double x1, double y1,
> >               double x2, double y2,
> >               double radius);
> > */
>
> This comes from PostScript's arct operator. The two points actually
> form two tangent lines---one from the current point to (x1,y1) and one
> from (x1,y1) to (x2,y2). These are not points on the spline at all.
>
> See the PostScript Language Reference Manual for a more detailed
> explanation.

Ah, ok.  That makes a lot of sense.  I was misleaded by the fact
that cairo_arc doesn't try to make a tangent at all.


> > but I cannot make any sense of it.  AFAIU the '_to' functions are
> > use the current point.  Then with x1,y1 and x2,y2 we would have
> > three points and there is a unique arc starting at current point,
> > passing x1,y1 and ending at x2,y2.  No need for radius.
>
> That wouldn't work. Given three arbitrary points in the plane there is
> not necessarily any arc that passes through all three points.

In fact it is.  There is a unique circle passing any three
non-linear points, and there is only one arc on this circle
starting at p0, passing p1, and finishing at p2.


> >   - This is not the '_to' version of cairo_arc.  A '_to' version
> > of cairo_arc makes no sense, since cairo_arc does not get an
> > starting point.
>
> I don't follow you here. There aren't '_to' versions of any functions
> in cairo. We have move_to, line_to, and curve_to, but never any
> variants of those without the '_to'.

Sorry.  Don't know what I've been drinking this morning.  Ignore.


> And cairo_arc does indeed get a starting point. It draws a line from
> the current point to the initial point on the arc. The proposed
> cairo_arc_to would do the same.
>
> >   - This definition of cairo_arc_to is hardly useful, since you
> > need to know a point on the arc, which is not quite obvious.
>
> This is actually a problem with the current cairo_arc as well. If the
> initial line_to is not desired, the application must manually compute
> the starting point of the arc and call cairo_move_to. I would still
> like to come up with some API addition to make this simpler, but I
> haven't decided any totally satisfactory names yet.

What about cairo_arc doing the move_to if the current path is
empty?


[...]
> As for the set-theoretic operations on paths. This would be very
> useful, but is a "hard" problem that we don't have a solution for yet
> within cairo. If we do end up writing the necessary code for this,
> I think it might make sense to split it out as a supporting geometry
> library under cairo, (since it would be quite useful for other things
> besides cairo).

I was actually thinking about porting the algorithms from
METAPOST.  But yes, that's better put in another library.


> >   - One more thing that I noticed is that in many places in the
> > code we(well, you :-) need to compute both sin and cos of the
> > same angle.  Most FPUs have a single instruction for doing this,
> > and glibc has a function for it too: sincos(3).  I think it's
> > worth using that.  Fortunately a simple implementation with no
> > drawback is possible:
> >
> > #if HAVE_SINCOS
> > #  define _cairo_sincos(angle,s,c) sincos((angle), (s), (c))
> > #else
> > #  define _cairo_sincos(angle,s,c) \
> >      do { *(s) = sin(angle); *(c) = cos(angle); } while (0)
> > #endif
>
> Please feel free to put a patch together for this change alone, (along
> with the necessary configure magic to define HAVE_SINCOS
> appropriately).

Ok.  Soon.


> Thanks for all your input,
>
> -Carl
>

--behdad
http://behdad.org/