[cairo] Backend API composite_trapezoids question

[Carl Worth]

On Fri, 27 Apr 2007 01:52:15 -0700, Per Persson wrote:
>   cairo_stroke(cr);
>
> As far as I understand things, the tessellated path is passed to
> composite_trapezoids() where I intercept it.

Almost. When you use cairo_fill, cairo's tessellator is called and
provides you with a set of non-intersecting polygons.

But with cairo_stroke, the tessellator isn't involved at all, and
instead a linear-time algorithm simply walks the path and emits
trapezoids as it goes. As you noticed, this process isn't careful to
avoid non-intersecting polygons at the line joins, (and to avoid
non-intersecting polygons in the case of a self-intersecting path
would basically require the same thing as running the tessellation
code).

I did write a version of cairo_stroke that computes the polygon of the
stroke, and then calls the tessellator on that to generate a list of
non-intersecting trapezoids. But that slows things down without much
benefit in most cases.

> Is this behaviour is expected?

For now, yes.

> If so, some post-processing of the trapezoids is obviuosly required
> and I'd be happy if anyone could provide me with pointers to some
> reasoning how this is supposed to work.

What the other cairo backends do here is that they render the set of
trapezoids to a single mask, and the composite with that mask.

That avoids the large problems you're seeing, (though it does
introduce single-pixel errors when the path intersects itself).

Would such an approach seem reasonable with your backend? If not,
you'll need to investigate changing the way cairo works here.

I hope that helps---and I hope you're having fun with cairo.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070427/6e28d632/attachment.pgp