[cairo] API Shakeup: cairo_current_path -> cairo_copy_path_data

[Bill Spitzak]

Carl Worth wrote:
> On Mon, 14 Mar 2005 21:15:56 -0800, Bill Spitzak wrote:
> 
>>I'm wondering if instead the structure should be:
>>
>>typedef union {
>>   struct {
>>     enum {
>>       ...
>>     } type;
>>     int length;
>>   } header;
>>   double value;
>>} cairo_path_data_t;
> 
> 
> You can find something much like that in Keith's original proposal
> near the top of this thread. In discussion, we decided that code like:
> 
> 	x1 = p[1].value;
> 	y1 = p[2].value;
> 	x2 = p[3].value;
> 	y2 = p[4].value;
> 	x3 = p[5].value;
> 	y3 = p[6].value;
> 
> was too messy to make the space savings worth it.

My argument is that you already do something like this for curves. There 
were previous proposals where the structure was big enough to hold a 
curve, and that was rejected. Since it appears nobody liked that and 
insisted on shortening it to the size of a point, why not shorten it 
even more.

My biggest worry is about 3D points. Homogenous coordinates are a 
multiple of 2 (xyzw) but I think it is a bit misleading to store the z 
in an x and the w in a y. Some other potential operators do not have an 
equal-sized set of x and y operators, such as trapazoids and 
axis-aligned segments (these may not be public but it would probably be 
a good idea for the internal path to be a compatable structure).

It is true that there are few, if any, modern operators where the number 
of arguments is not a multiple of 2. 3D usually supports homogenous 
coordinates and colors always include alpha.