[cairo] Overhead reduction

Jonathan Morton jonathan.morton at movial.com
Thu May 14 06:41:51 PDT 2009


Hi,

While working on performance improvements to the blitters, we noticed
that calls via XRender had a lot of overhead, which was slowing down
small requests in general, and glyph rendering in particular.

Attached is a series of patches which reduces this overhead in both
pixman and X.org.  All of these improvements are essentially
platform-independent.

Most of the changes are based around avoiding malloc/free cycles in the
clip-region and picture-object handlers.  There were about five or six
malloc cycles during a typical call to render a single, already-cached
glyph, and they consumed a large amount of the CPU time on our test
platform.

Glibc's malloc is reasonably quick as general-purpose mallocs go, but it
is still slow enough to avoid using when possible.  Mallocs on some
other popular platforms are considerably less efficient.

Even after these patches, pixman still has quite a lot of overhead,
which hopefully the refactoring will address to some extent.  However,
these patches have been observed to more than double performance in some
situations, and have not been observed to reduce performance.

The malloc replacements' operation should be fairly obvious - there are
three new object pools and one use of alloca().

It should be noted that the object pool implementation is not
thread-safe - if this is inappropriate, modifications will be required
to use atomic_test_and_inc/dec operators.  Leak detectors might also
complain about the pools, since they are not drained on shutdown.
Suggestions on these matters are welcome.

Major surgery is also performed on miGlyphs() in X.org.  This has two
goals:

1) Use a persistent scratch pixmap instead of reallocating it for every
glyph operation.  Since this is of a fixed size (1024x64), provision was
made to fall back to operation without a scratch pixmap when necessary,
which should improve reliability in low-resourced conditions (previously
it would cancel the whole draw operation).

2) Avoid using the scratch pixmap when there is only one glyph to draw,
which is unnecessary overhead.

I'm not sure whether this is the best place to shove an xserver patch,
but since it goes with the pixman one...  oh well.  :-)

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pixman-fastregion32.patch
Type: text/x-patch
Size: 736 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090514/fc0b0f27/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pixman-imagepool.patch
Type: text/x-patch
Size: 1032 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090514/fc0b0f27/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorg-server-fastglyphs.patch
Type: text/x-patch
Size: 5746 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090514/fc0b0f27/attachment-0002.bin 


More information about the cairo mailing list