[cairo] Re-working cairo_current_path

[Kristian Høgsberg]

Owen Taylor wrote:
> 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.

Ah, right, take the length out of the cairo_path_element_t and keep 
knowledge of element size inside cairo.  Yeah, that's better and makes 
it possible to adjust the path representation later on if necessary.

Kristian