[cairo] libpixman - libpixregion, libic and slim merged; cairo built with it

[Keith Packard]

Around 15 o'clock on Dec 9, Carl Worth wrote:

> We should probably take this chance to clean up the worst warts in the
> interface too. For example, PixRegion is inconsistent with respect to
> box vs. rect(s). My recommendation would be:

'box' objects contain x1,y1 -> x2,y2 values, 'rectangles' contain x,y 
width,height values.  Doing that consistently will at least avoid driving 
me insane.

I don't know which interface to prefer for external use.  Internally, 
boxes are *way* easier to do computations with because the values are 
independent, but I realize that many existing external interfaces have 
rectangles for some reason.

> Much worse is the disgusting fact that PixRegionAppend leaves an
> invalid region. The call to PixRegionValidate should be absorbed into
> the implementation of PixRegionAppend, and PixRegionValidate can be
> removed from the interface.

Why don't you just eliminate both of these.  They're special cases used 
within the X server to speed up window region computations.  If the 
underlying region structure is visible, then the server can code up these 
functions independently.  And, given that we have over 10 years
experience with the current datatypes, it doesn't seem crazy to make them 
public even at the risk of freezing out development of alternative 
datastructures.

One thing we might do is tag the region datatypes with the fundemental 
coordinate datatype somehow (like pixman_int16_t and pixman_box16_t) so 
that we can create a pixmap_box32_t when the pixel coordinate space 
expands beyond 16 bits.  With PostScript output at 2400dpi, we're already 
limited to 13 inches, which seems rather tight.

-keith