<br><br><div class="gmail_quote">2011/6/20 Andrea Canciani <span dir="ltr"><<a href="mailto:ranma42@gmail.com">ranma42@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Mon, Jun 20, 2011 at 8:10 AM, Taekyun Kim <<a href="mailto:podain77@gmail.com">podain77@gmail.com</a>> wrote:<br> > Thanks for the replay.<br> ><br> >> Basically when you use a Bounded operator, you are not touching anything<br> >> outside the extents of your mask, while an XRender operator can change the<br> >> destination even outside the mask.<br> >> For example if you do an "IN" operation, everything outside the mask but<br> >> inside the clip becomes transparent.<br> ><br> ><br> >><br> >> The equation which follows from the description is:<br> >> dst' = ((src IN mask) OP dst) LERP_clip dst<br> >><br> >> In particular, it explains the (src IN mask) part, i.e.<br> >> the source is cleared outside the mask.<br> ><br> > Ok, now I clearly understand why CLEAR and SOURCE should be explicitly<br> > bounded by mask. If (zero OP dst) == dst, we can classify these operators as<br> > "Any" (same for both bounded and unbounded interpretation). For remaining 4<br> > unbounded operators, result of compositing zero with dst is always zero i.e.<br> > (zero OP dst) == zero, where OP = IN, OUT, DEST_IN, DEST_ATOP.<br> > So following equation should hold for 4 unbounded operators.<br> > dst = (src IN mask) OP dst (where mask is allowed)<br> > dst = zero (where mask is not allowed)<br> <br> </div>I'm not sure about the meaning of "mask is allowed". Is it referred to clipping?<br> If you assume no clipping, the formula for unbounded ops is simply:<br> <div class="im">dst' = (src IN mask) OP dst<br> </div>no matter what the mask is.<br> Where you are clipped away, no change is performed, so dst' = dst.<br> <div class="im"><br></div></blockquote><div><br></div><div>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.</div> <meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"> ><br> >><br> >> > 3. Limit boxes<br> >> > Boxes, traps, polygon can have there limit boxes. I thought the boxes<br> >> > should<br> >> > be disjoint,<br> >> > because I couldn't find any handling of overlapping boxes. Is this true?<br> >><br> >> No, overlappping boxes are handled by the tessellator and/or the<br> >> rasterizer.<br> ><br> > I used the term "boxes" referring to the "limit boxes". I know that boxes<br> > (not limit boxes) are tessellated according to the fill rule by<br> > cairo_bentley_ottmann_tessellate_boxes(). But I couldn't find any accessing<br> > to limits and num_limits inside of tessellator code. Instead, in case of<br> > polygon, an edge is clipped with each of limit boxes before it is added. So<br> > if the limit boxes should be regarded as a set of rectangular paths rather<br> > than rectangular region, we have to consider the fill rule of the limit<br> > boxes. But edge clipping does not consider the fill rule of the limit boxes.<br> > This is also same for cairo_traps_t. So, I concluded that limit boxes should<br> > be disjoint (regional representation) so that we can ignore the fill rule.<br> <br> </div>Sorry, I misunderstood your question.<br> Yes, IIRC limit boxes are assumed to be disjoint.<br> <br> Side note:<br> Skimming through the cairo-polygon code made me wonder if the<br> implementation of the fill code is actually correct...<br> To me it looks like there might be problems if an edge is clipped away.<br> I'll look deeper into this and try to prepare a testcase.<font color="#888888"><br> </font></blockquote></div><br><div>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.</div> <div><div><div><div><br>-- <br>Best Regards,<div>Taekyun Kim</div><br> </div></div></div></div>