[cairo] Pixman Performance Regressions

Soeren Sandmann sandmann at daimi.au.dk
Sat Aug 8 16:44:05 PDT 2009


Chris Wilson <chris at chris-wilson.co.uk> writes:

> On Fri, 2009-08-07 at 00:07 +0200, Soeren Sandmann wrote:
> > The glyph regresssion for the image backend is because the image
> > backend unlike the X backend is drawing glyphs in a way that doesn't
> > have fast path support in pixman. This means many calls to the general
> > path with small images. In master this is inherently slower because we
> > now do proper clipping instead of relying on region calculus. I'm not
> > sure there is a general fix for this, but we can fix the concrete
> > symptom by writing fast paths for glyph rendering.
> 
> More fast paths for glyphs is always good news! Can you explain what the
> difference is between doing proper clipping and using regions? Is this
> something that cairo can take advantage of?

In Render and pixman all operators are "unbounded" in cairo
terminology. For some operators unbounded happens to coincide with
bounded, but for others it doesn't. So in general pixman can't clip
compositing to the bounding box of the source because pixels outside
that bounding box can have an effect eventhough they are zero.

In earlier versions, pixman would actually clip to the source bounds
in the untransformed, non-repeating cases, which meant operators like
IN and SRC would produce incorrect results. The clip-in pixman test
has a test case.

As a result of fixing this, the untransformed image scanline fetchers
can now be asked to fetch outside the image bounds, and if they are,
they need to generate 0s. There is some small, but unavoidable
per-scanline overhead associated with this, even when the clip region
is completely inside the source image.  See

        bits_image_fetch_untransformed_none()

This overhead is particularly visible for small images such as glyphs.


Soren


More information about the cairo mailing list