[cairo] Backend API composite_trapezoids question
cworth at cworth.org
Fri Apr 27 09:13:18 PDT 2007
On Fri, 27 Apr 2007 01:52:15 -0700, Per Persson wrote:
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070427/6e28d632/attachment.pgp
More information about the cairo