[cairo] Performance of the image surface back-end

Nicholas Allen allen at ableton.com
Fri Aug 15 06:20:42 PDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi,

I was just evaluating the possibility of using Cairo for rendering as it 
has a very clean API and produces great looking output. We have our own 
custom in-house basic 2D graphics API which only deals with integer 
coordinates and does no anti-aliasing. Currently, this is not a problem 
for us because our widgets always draw on pixel boundaries and we draw 
very few diagonal lines. However, we would like to add curve drawing and 
so I am investigating using Cairo for rendering bezier curves and other 
sub-pixel primitives. Before doing so I decided to benchmark Cairo to 
make sure adding curve drawing primitives would not slow down rendering 
of our most common primitives.

The most common operations we do is filling rectangles (on integer pixel 
boundaries) and drawing horizontal and vertical lines (also on pixel 
boundaries) so these operations need to be as fast as possible. I 
wouldn't say our implementations of these primitives was especially 
optimal - it did not take us long to write them and we have not spent 
extensive time optimizing them. However, in my preliminary evaluation of 
Cairo they are enormous magnitudes faster than Cairo's image surface 
back-end.

Cairo (image surface back-end version 1.6.4 on Windows):

~     DrawHorizLine                 44352 ms             1000000 solid 
horiz lines from 0.5, 50.5 to 500.5, 50.5
~     DrawHorizLine with alpha   61941 ms           1000000 semi 
transparent horiz lines from 0.5, 50.5 to 500.5, 50.5
~     DrawVertLine               23099 ms                 100000 solid 
vert lines from 50.5, 0.5 to 50.5, 500.5
~     DrawVertLine with alpha    23094 ms            100000 semi 
transparent vert lines from 50.5, 0.5 to 50.5, 500.5
~     DrawDiagonalLine           114357 ms             100000 solid 
lines from 0.5, 0.5 to 500.5, 500.5
~     DrawDiagonalLine alpha     94721 ms            100000 semi 
transparent lines from 0.5, 0.5 to 500.5, 500.5
~     DrawFilledRect             2483 ms                    100000 solid 
rectangles 500x500
~     DrawFilledRect with alpha 1468  ms               100000 
semi-transparent rectangles 500x500


Ours:

~     DrawHorizLine              201 ms               (221 X faster)
~     DrawHorizLine with alpha   421 ms          (147X faster)
~     DrawVertLine               266 ms                (87 X faster)
~     DrawVertLine with alpha    767 ms           (38 X faster)
~     DrawDiagonalLine           9770 ms            (12 X faster)
~     DrawDiagonalLine alpha     9690 ms         (9.8 X faster)
~     DrawFilledRect             902 ms                (2.8 X faster)
~     DrawFilledRect with alpha  246ms            (6 X faster)


I am amazed that our reasonably simple and quick implementations are so 
significantly faster than Cairo's. I realize Cairo is a more generic API 
but I had expected it to fall back to reasonably efficient 
implementations for common cases like filling rectangles on pixel 
boundaries and drawing horizontal and vertical lines. I expect, these 
are probably the most common cases for operations inside GUI programs 
where widgets draw and fill rectangles on pixel boundaries and that our 
application is not unique in these requirements.   I realize that I have 
not used the latest Cairo but it did not seem from the change log that 
much work has been done on optimizing the image back-end and I could not 
find a pre-build 1.7.4 version for Windows.

Unfortunately, this means Cairo is completely unusable for us. Can 
anyone enlighten me on why Cairo is so extremely slow and if there are 
any plans to address these issues in future releases? Does Cairo not 
special case pixel boundaries and solid colors. Does it not move as much 
computation out of loops as possible? Does it make any use of the vector 
unit in modern CPUs? Can I use a different back-end to render into image 
buffers than the image surface one on Windows or Mac to achieve better 
performance
~ (we need to render in 32bit ARGB pre-multiplied format)? Any help or 
suggestions greatly appreciated.

Thanks,

Nicholas Allen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFIpYKqbpmWsXfOU58RAnSJAKCbM3ncuuWxkwWHxrmTDEolg5OJ7gCfQwtN
NNMqWZR28meQuK6yfP9E1N8=
=SRmb
-----END PGP SIGNATURE-----



More information about the cairo mailing list