[cairo] Region code...

[Bill Spitzak]

Matthew Allen wrote:
> b) There is no path type. so you can't build up a path and reuse it later. there apears to be some hints towards moving in that direction in the header though. It'd certainly make sense in some applications to have an opaque path type, ala Gdi+'s Gdiplus::Path.
> c) There is no api for working with regions. Obviously internally there is some sort of region code but there is no external api for it. How hard would it to be to add such an api? To do things like create, delete, intersect, union, subtract etc? A path type is useful in this regard as well.

It has been pointed out that intersecting two paths to produce a new 
path is really difficult and Cairo is not doing this. So a region is 
*not* a path.

Still it could be very useful, perhaps more useful than a path object. 
As I see it, it is a representation of an arbitrary alpha mask, and an 
implementation is allowed to have rasterized it. It probably contains 
rectangles, trapazoids, paths, but may also contain alpha bitmaps and 
the transformation to arrive at that bitmap, and using a region where 
the transformation to pixels is different is either very slow or perhaps 
undefined. In any case I very much recommend that the internal structure 
be entirely opaque, there is no calls in the Cairo api to enumerate or 
otherwise peek into a region.

The Cairo API would have to provide:

	Copy the current region
	Copy the current path, filled, as a region
	Copy the current path, stroked, as a region
	Copy the current surface's alpha as a region.
	Create an infinitely large region
	Create a region that is a rectangle
	Create a region from the alpha channel of an in-memory image?
	Intersect, union, and difference two regions
	Destroy a region.
	Test to see if a region is empty
	Intersect a region with a bounding box and return the minimum-size 
bounding box that surrounds the intersection. (the reason this takes a 
bounding box as input is so that a representation for infinity is not 
needed).

Because Cairo should be unable to draw outside the current clip region, 
the only "input" functions from regions into the graphics state should be:

	Replace the current region with the intersection of it and the passed 
region.
	"Fill" the region. The result of turning a path into a region and then 
filling it is identical to filling the path.

i.e there must *not* be a "set the region to this" call.