Created attachment 4587 [details] [review]
cairo-win32-alphablend.patch

Patch that changes this; the patch also adds cairo_win32_surface_get_dc for
extracting out the HDC from a win32 surface (so that a surface created via
create_similar can have its DC pulled out for non-cairo operations).

Is the Win32 software implementation noticeably faster than the
libpixman one? Is the libpixman implementation you are using
compiled with or without fbmmx?

(As far as I remember, a surface with destination alpha is always
a memory surface.)

Is there any documentation that AlphaBlend handles destination
alpha? I see nothing about that in the msdn docs.

The docs for BLENDFUNCTION
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmaps_3b3m.asp)
imply that it handles it; that is, it explicitly talks about "If the destination
bitmap has an alpha channel, then the blend is as follows [...]".

No MMX compiled; so far the mmx code only works with gcc, but I'll be
integrating the mmx patches for vs at some point soon.  As for whether it's
faster, that I can't tell you; it certainly doesn't feel any slower, and it
seems like we should use it if it's available, especially since it might be
hardware accelerated.

Hmm. Yeah. Though it's sort of weird to say "if the destination bitmap
has an alpha channel" since the only representation of alpha in GDI
drawing calls *at all* is being a source for AlphaBlend... 

But if it experimentally works, we can use it until someone has problems...

The other point I was making is that this case always involves the 
destination surface being a DIB, so hardware acceleration isn't
a factor. Thus, you are just replacing the cross-platform software
code (fastish, but not super-optmized except for the fbmmx code) with
Microsoft's code.

That's why I was interested if you had any speed comparisons.

Wasn't this discussed in detail on the mailing list recently?  Close?

This patch has been folded into the tree and has since evolved...