[cairo] Re: new clipping change patch

[Keith Packard]

On Wed, 2005-05-25 at 14:51 -0400, Owen Taylor wrote:

> Hmm, so you are getting bitten by delaying setting the clip in fear
> of someone else changing the clip in the meantime. I'm not convinced
> that delay is that useful, but given that, the allocate-ids scheme
> should work.

Not in this case; I'm just making sure an ID is allocated for each
unique region that *might* be applied as a clip at some point, and
allocated as early as possible in case that region is copied to another
gstate so that we can avoid resetting clips whenever these two regions
are used back-to-back.


> I don't really have a strong feeling here. Certainly a fair number of
> operations are easier to code on boxes, but you could argue for 
> rectangles on analogy to the public API. I *don't* like at all the
> fact that cairo_box_t is fixed point while cairo_rectangle_t is 
> integer. 

I think this is a separate discussion, the current internal API uses
rectangles everywhere, so I will make this patch use rectangles as well.
I found _cairo_rectangle_intersect in cairo-gstate.c which appears to
work correctly in this case.


> I think what you are saying is that a 16-bit rectangle 
> 
>  x=32757, y=32767, width=65535, height=65535
> 
> or whatever is isn't representable as a pixman_region16_t, while all
> boxes are representable as pixman_region16_t.

Right.  As a part of the separate discussion about box vs rectangle, it
is important to realize that the 'rectangle' type doesn't form a group
over the coordinate set operations leaving many of them ill-defined.
Using a type which covers exactly the output coordinate space makes all
of these operations easier to specify and eliminates a bunch of error
checking on input parameters.

> Is that really relevant? We don't care about the parts of the coordinate
> space outside of the (-32768,-32768) ... (32767,32767) range, so
> clamping to that range when converting to region should be fine. 

Yes, clamping to 16-bits is just fine, and boxes naturally enforce this
restriction while rectangles permit invalid values to be carried
around. 

But, as said above, all of this is not germane to this particular thread
and we should start another one on the whole issue of internal extents
representation (as well as the public API problem of cairo_fill_extents
taking coordinates while cairo_rectangle takes dimensions...)

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050525/964ed099/attachment.pgp