[cairo] Recent commit of cairo-test-trace (which is very cool, by the way!)

[Chris Wilson]

On Fri, 2009-06-12 at 15:52 -0700, Carl Worth wrote:
> On Fri, 2009-06-12 at 14:29 -0700, Chris Wilson wrote:
> > +/* XXX Can't directly compare fills using spans versus
> > trapezoidation,
> > + *     i.e. xlib vs image. Gah, kinda renders this whole scheme moot.
> > + *     How about reference platforms?
> > + *     E.g. accelerated xlib driver vs Xvfb?
> > + *
> > + *     boilerplate->create_reference_surface()?
> > + *     boilerplate->reference->create_surface()?
> > + *     So for each backend spawn two processes, a reference and xlib
> > + *     (obviously minimising the number of reference processes when
> > possible)
> > + */
> 
> The other option would be to get rid of all the trapezoid-based code
> paths. They're not actually helping anywhere, right?

Besides the fact they are the fallback for cases spans does not yet
handle (non-antialiasing and strokes) I think there is life in the old
tesselator yet. I have some performance tuning on the self-intersecting
branch that showed promise of squeezing an extra 10-30% out of the
tesselator and combining that with stroke-to-path and greedy
trapezoidation can improve tesselation+rasterisation by up to 2-3x.
(Enough to compensate for the overhead of doing full-stroke tessellation
for self-intersection removal. At least for perf/world-map. It will be
interesting to look at the performance of cairo-traces with
self-intersecting...

> And shouldn't it be easier to accelerate spans anyway?
Yes, converting spans to GL_LINES or rectlists is fairly trivial, much
easier than rasterising trapezoids at least. However the traps do offer
one significant advantage over the current implementation of spans -
they encompass information about much larger areas in a single pass.
Although nobody has yet done so, it can't be that hard to write a shader
to achieve pixman quality antialiased traps...

On the subject of spans/traps, I'd also like to investigate geometric
clipping. The poppler cairo-trace is slow because every operation is
performed under a non-aligned clip, which causes ridiculously bad
behaviour (generates lots of scratch pixmaps which need several domain
transfers thus stalling the gfx pipeline). Adapting the tesselator to
produce clipped trapezoids is fairly simple - fixing the mess of cairo's
internal clipping API will take longer. Another interesting goal here
would be to investigate "Transparency should be optionally flattened to
a new path rather than a bitmap".

So a few ideas for 1.12. :-)
-ickle