[cairo] Performance of the image surface back-end

[Nicholas Allen]

-----BEGIN PGP SIGNED MESSAGE-----
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
line.

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.

Cheers,

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

iD8DBQFIp+XX1+i51gqqEGkRAkPdAJ9fFDGN77aZOgW8MENDMFRY5W2TTgCgj62f
z9iy8gfhaabHOvKgWefhrEo=
=KGhy
-----END PGP SIGNATURE-----