[cairo] Re-working cairo_current_path
Owen Taylor
otaylor at redhat.com
Mon Jan 24 10:39:57 PST 2005
On Mon, 2005-01-24 at 13:30 -0500, Kristian Høgsberg wrote:
> Keith Packard wrote:
> > Around 11 o'clock on Jan 24, Carl Worth wrote:
> >
> >
> >>Keith, what was your proposed data structure for the path? A list of
> >>double with magic values to specify each operator?
> >
> >
> > Perhaps:
> >
> > typedef union {
> > struct {
> > enum { Move, Draw, Curve } Type;
> > uint16_t len;
> > } head;
> > double value;
> > } cairo_path_elt_t;
> >
> > Or is that too complicated? It seems like a feature to encode the length
> > of each element right into the element; it might permit the kinds of
> > elements to be extended in the future (and exposed in some new call)
> > without completely wrecking all existing code.
> >
> > But, I'd support the simpler
> >
> > #define CAIRO_PATH_MOVE 0.0
> > #define CAIRO_PATH_DRAW 1.0
> > #define CAIRO_PATH_CURVE 2.0
> >
> > if that seems nicer.
> >
> > (oh, the names above are unconsidered and should be taken only as
> > representative of the structure of the objects)
>
> What about:
>
> struct cairo_path_element {
> enum { move, draw, curve } type;
> uint16_t length;
> union {
> struct { double x, y; } move_to;
> struct { double x, y; } line_to;
> struct { double x1, y1, x2, y2, x3, y3 } curve_to;
> };
> };
>
> possibly with a CAIRO_PATH_ELEMENT_NEXT macro that does the pointer
> arithmetic to get the next element.
Would an opaque type with an iterator API work? E.g.:
cairo_path_iterator iter;
for (have_element = cairo_path_iterator_begin (path, &iter);
have_element;
have_element = cairo_path_iterator_next (&iter)) {
switch (cairo_path_iterator_current_element (&iter)) {
case CAIRO_PATH_MOVE_TO:
{
double x, y;
cairo_path_iterator_get_move_to (&iter, &x, &y);
[...]
}
break;
}
}
Or:
cairo_path_iterator iter;
int have_element;
for (have_element = cairo_path_iterator_begin (path, &iter);
have_element;
have_element = cairo_path_iterator_next (&iter)) {
cairo_path_element_t *element = cairo_path_iterator_current_element (&iter);
switch (element->type) {
case CAIRO_PATH_ELEMENT_MOVE_TO:
/* Do stuff with element->move_to.x element->move_to.y; */
}
}
Which I guess is Kristian's proposal, but less reminiscent of the API
disaster that is XInput.
Regards,
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050124/1d514fff/attachment.pgp
More information about the cairo
mailing list