[cairo] Performance of the image surface back-end

Nicholas Allen nick.allen at onlinehome.de
Sun Aug 17 01:48:23 PDT 2008

Hash: SHA1

> The problem in your case is that the line caps are -not- drawn.  A
> stroke which results in a fully pixel-aligned outline is just a fast
> solid fill.  One that's not pixel aligned (such as one that's offset by
> 0.5 pixel that causes the stroke outline to fall on a non-pixel
> boundary) ends up going through the slower rendering path because of the
> antialiasing that has to happen at that half pixel.  This is, as you
> say, not ideal, and some optimization is certainly possible (and some is
> in progress), and it is certainly slower than code that only has to deal
> with pixel-aligned strokes without any antialiasing.

Thanks for the info. I will definitely try making the line pixel aligned
tomorrow and see what difference that makes. I am surprised that Cairo
does not draw the 498 pixels that aren't anti-aliased using a fast
algorithm and the remaining end pixels separately. I wonder if it would
be faster if I called the rect filling code for a horizontal or vertical

The rectangle filling code also seems to be incredibly slow and I am
pretty sure I have that on pixel boundaries. It seems there is pleanty
of room for improvement here.

Do you think, on Mac OS X at least, using the quartz back-end to render
into an image buffer could be faster? I looked into using Windows GDI
backend to render into a bitmap but Windows GDI is an extremely basic
graphics API and I can't even find a way to create a bitmap in ARGB 32
pre-multiplied alpha format for an already allocated buffer so I didn't
pursue that any further.


Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the cairo mailing list