This might be a duplicate of bug #91191, but I am not really sure...

I have problems using libart to render certain polygons. Mostly it works
fine, but sometimes the results are unusable.
I use libart 2.3.16 from Debian Testing. To render a libart path to
a gimp drawable I basically use the sequence

    pert_vpath = art_vpath_perturb (vpath);
    svp  = art_svp_from_vpath (pert_vpath);
    svp2 = art_svp_uncross (svp);
    svp3 = art_svp_rewind_uncrossed (svp2, ART_WIND_RULE_ODDEVEN);

This sequence mostly works fine, but I stumbled across a polygon, where
this does not work at all. However, this polygon renders fine, when
not using art_vpath_perturb(). At first I thought, that simply removing
that call would solve the problem, but soon I stumbled
across different polygons that *needs* the call to be rendered
correctly.

So I cannot avoid these warnings and artefacts when I don't have a control
over the polygons passed to libart.

Attached is a standalone program that can render two polygons, one that
results in warnings and artefacts when using _perturb() and one that
results in warnings and artefacts when avoiding _perturb().

it compiles with
gcc `pkg-config --libs --cflags libart-2.0` -o libart-problem libart-problem.c

A few sample invocations are:
   ./libart-problem -p bricks    # proper calculation of the "bricks" polygon
                                 # (with _perturb())
   ./libart-problem +p star      # proper calculation of the "star" polygon
                                 # (without _perturb())

If you want to see the rendered polygon, pass an additional "-r" on the
commandline and pipe stdout to an image viewer (e.g.
 ./libart-problem -r +p star | display )

Exchanging +p and -p results in lots of ugly libart messages to stderr,
and the rendered polygon is also garbled.

Also I'll attach an image showing the artefacts.