[cairo] Very slow performance

Keith Packard keithp at keithp.com
Thu Dec 23 10:20:36 PST 2004


Around 9 o'clock on Dec 23, Chris wrote:

> I made a simple test program that loads this file and renders it to an
> image buffer in Cairo.  It takes over 30 seconds to do this.  That's
> incredibly slow and makes me wonder about the usability of Cairo in
> everyday applications.  

Performance hasn't been a critical concern for cairo development until 
now; we've been much more focused on API structure and cross-language 
usability.

There isn't anything inherant in the structure of the cairo implementation 
causing these performance problems.  As we get more experience with how 
cairo is used in real applications, and do some real performance 
measurements, we'll be able to find the bottlenecks in cairo and all of 
the underlying systems.

This week alone saw some analysis from the xpdf cairo back-end development 
speed text drawing up by a huge factor (10000) caused by a small 
collection of easily fixed bugs.

There are some obvious places where code improvements will yield 
substantial benefits.  

One such place is in the primitive image compositing code which was written
as quickly as possible a few years ago to complete the Render extension
inside the X server.  Two pieces are needed here; the first is some
mechanism for easily and accurately plugging in new acceleration functions,
the second is a replacement for the pixel-at-a-time software fallback
rendering code.  

Another place is in the polygon rasterization code.  Two pieces are also 
needed here; the first is a new tesselator.  Carl has done the research 
necessary to build what we need, so it should be only a matter of 
programming time before this task is complete.  The second piece is an 
efficient primitive trapezoid filler.  We want to compute 8 bits of alpha 
information, and the traditional methods for drawing anti-aliased polygons 
all scale linearally in the number of alpha values.  255 is a large scale 
factor.  I have some ideas on how to make this faster, but if they don't 
pan out, we may end up with 'fast' and 'pretty' modes, something which 
we've avoided successfully in other areas of cairo until now.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041223/cbd5e436/attachment.pgp


More information about the cairo mailing list