# [cairo] Questions about operators, clipping and etc

Andrea Canciani ranma42 at gmail.com
Mon Jun 20 02:21:12 PDT 2011

```On Mon, Jun 20, 2011 at 8:10 AM, Taekyun Kim <podain77 at gmail.com> wrote:
> Thanks for the replay.
>
>> Basically when you use a Bounded operator, you are not touching anything
>> outside the extents of your mask, while an XRender operator can change the
>> destination even outside the mask.
>> For example if you do an "IN" operation, everything outside the mask but
>> inside the clip becomes transparent.
>
>
>>
>> The equation which follows from the description is:
>> dst' = ((src IN mask) OP dst) LERP_clip dst
>>
>> In particular, it explains the (src IN mask) part, i.e.
>> the source is cleared outside the mask.
>
> Ok, now I clearly understand why CLEAR and SOURCE should be explicitly
> bounded by mask. If (zero OP dst) == dst, we can classify these operators as
> "Any" (same for both bounded and unbounded interpretation). For remaining 4
> unbounded operators, result of compositing zero with dst is always zero i.e.
> (zero OP dst) == zero, where OP = IN, OUT, DEST_IN, DEST_ATOP.
> So following equation should hold for 4 unbounded operators.
>     dst = (src IN mask) OP dst (where mask is allowed)
>     dst = zero (where mask is not allowed)

I'm not sure about the meaning of "mask is allowed". Is it referred to clipping?
If you assume no clipping, the formula for unbounded ops is simply:
dst' = (src IN mask) OP dst
no matter what the mask is.
Where you are clipped away, no change is performed, so dst' = dst.

>
>>
>> > 3. Limit boxes
>> > Boxes, traps, polygon can have there limit boxes. I thought the boxes
>> > should
>> > be disjoint,
>> > because I couldn't find any handling of overlapping boxes. Is this true?
>>
>> No, overlappping boxes are handled by the tessellator and/or the
>> rasterizer.
>
> I used the term "boxes" referring to the "limit boxes". I know that boxes
>  (not limit boxes) are tessellated according to the fill rule by
> cairo_bentley_ottmann_tessellate_boxes(). But I couldn't find any accessing
> to limits and num_limits inside of tessellator code. Instead, in case of
> polygon, an edge is clipped with each of limit boxes before it is added. So
> if the limit boxes should be regarded as a set of rectangular paths rather
> than rectangular region, we have to consider the fill rule of the limit
> boxes. But edge clipping does not consider the fill rule of the limit boxes.
> This is also same for cairo_traps_t. So, I concluded that limit boxes should
> be disjoint (regional representation) so that we can ignore the fill rule.