[cairo] Questions about operators, clipping and etc

[Taekyun Kim]

2011/6/20 Andrea Canciani <ranma42 at gmail.com>

> 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.
>
>
Sorry for confusion. I assumed no clipping. Because zero OP dst is always
zero for unbounded ops, dst = zero also should hold. So fast paths which do
not use temporary mask can safely fixup unbounded ops by just clearing dst
where geometry is not drawn. If we take clipping into account, result would
be LERP between the above unclipped result and dst. That's what I understand
for current implementation of image backend functions. So everything is
clear now. Thank you for the kind explanation.



> >
> >>
> >> > 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.
>
> Sorry, I misunderstood your question.
> Yes, IIRC limit boxes are assumed to be disjoint.
>
> Side note:
> Skimming through the cairo-polygon code made me wonder if the
> implementation of the fill code is actually correct...
> To me it looks like there might be problems if an edge is clipped away.
> I'll look deeper into this and try to prepare a testcase.
>

I'm not sure but it seems that _add_clipped_edge() function can cause
problems. If an edge is horizontally fully outside, it will be reduced to a
vertical edge more than twice resulting incorrect even-odd or winding count.

-- 
Best Regards,
Taekyun Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110620/c194d3e1/attachment.htm>