[cairo] [PATCH] rectangle clipping regions

[Carl Worth]

On Dec 15, graydon hoare wrote:
 >    - new call: cairo_init_clip (cairo_t *cr); which resets the clip
 >      region to the entire device. mimics what postscript does here,

This looks just fine. Adding new API calls that match PostScript

 >    - new surface backend function:
 > 
 >      cairo_int_status_t
 >      (*set_clip_region)		(void			*surface,
 > 				 pixman_region16_t	*region);

This looks fine too. As far as the internal backend interface, pretty
much anything that gets the job done is OK with me, (though I do want
to do some housekeeping in that department soon).

 >    - new functionality in cairo_gstate: gstate holds both a clip
 >      mask and a clip region (possibly NULL). when cairo_clip runs,

This seems like a slick feature. It should satisfy the need for fast
clipping of pixel-aligned rectangles, but without complicating the
API. Well done.

 > there are a couple FIXMEs: I don't know what to do on the postscript 
 > backend

OK. I may be able to look at the PS backend sometime, (it's actually
simpler than it looks, basically it all just defers to the image
backend for everything --- though the code path there isn't obvious at
first glance).

I would not like to see this committed unless we're sure that the PS
backend is still working.

 > and I don't have a particularly good epsilon available for 
 > measuring pixel alignment of the clip path (I'm currently checking to 
 > see if bits 8-15 are clear).

At this point, you've got a fixed-point value so no epsilon should be
necessary. You just want to check if the sub-pixel portion is 0. So
just modify the code to check that bits 0-15 are clear. (Note: I had
misread the code when I made an earlier offline comment to you.)

 > I'm also not sure if:
 > 
 >     - the clip should always be added to the mask *as well* as the region
 > 
 >     - the bounding box of non-rectangular paths should be added to the
 >       region, perhaps to speed up compositing (?)

To me, those both sound like further optimizations. They're probably a
good idea, but since all of this work is just optimization anyway,
there's no need to delay this patch for these.

-Carl