Re: [LIBART] unfilled areas when drawing with transparency (alpha) ?

["Pierre Arnaud" <pierre arnaud opac ch>]

> I just ran into an interesting behaviour of libart where certain types of
> areas aren't filled in when using any amount of transparency (alpha level
> other than 0xFF).  The situation happens when I give the vertices of an
> area in a clockwise order.  Compare these two images:
> 
>   http://www.folta.net/drew/fill_EE.png
>   http://www.folta.net/drew/fill_FF.png

This is a deficiency in libart. Libart should not draw anything for
figures where the outline is defined clockwise. I also ran into it. The
official answer I got was the following (from Alexander Larsson) :

-----------------------------------------------------------------------
The libart svp rasterization primitives accept only what libart
sometimes calls "clean" SVPs, i.e. the winding number is 0 or 1 at each
point. If you know that your SVPs are the in the correct order and are not
self-intersecting you can use them as is. Otherwise you must use
art_svp_rewind_uncrossed() (and art_svp_uncross before that) to create a
clean SVP. When you do this you have the following alternatives for how to
interpret the winding number:

 * With @rule == ART_WIND_RULE_NONZERO, the resulting svp has a
 * winding number of 1 where @vp has a nonzero winding number.
 *
 * With @rule == ART_WIND_RULE_INTERSECT, the resulting svp has a
 * winding number of 1 where @vp has a winding number greater than
 * 1. It is useful for computing intersections.
 *
 * With @rule == ART_WIND_RULE_ODDEVEN, the resulting svp has a
 * winding number of 1 where @vp has an odd winding number. It is
 * useful for implementing the even-odd winding rule of the
 * PostScript imaging model.
 *
 * With @rule == ART_WIND_RULE_POSITIVE, the resulting svp has a
 * winding number of 1 where @vp has a positive winding number. It is
 * useful for implementing asymmetric difference.

If you do this the rendering primitives will work with your SVPs and you
will not get the kinds of issues that the GIF you sent shows.
-----------------------------------------------------------------------

But you will find out that you will also have to perturb the paths
in order to avoid some special cases where libart is not numerically
stable. But this is another story...

Hope this helps.

    Pierre

PS: I suggest you try some other library, like AGG2 (www.antigrain.com)
    which is getting quite stable now.