[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