[cairo] Weird fill vs stroke behavior on Windows

[Vladimir Vukicevic]

On 3/30/09 10:48 AM, Travis Griggs wrote:
> I have a segment of code which creates a cr on a Windows HDC from an
> hBitmap. I then draw to it using the following series of (pseudo)
> statements:
>
> rectangle(0, 0, 100, 100);
> sourceRGBA(0.5, 0.5, 0.5, 1);
> fill();
> sourceRGB(0.625, 0, 0.875);
> moveTo(0, 0);
> lineTo(40, 30);
> strokeWidth(1);
> stroke();
>
> When I look at the bitmap bits though, it's weird. Wherever the stroke
> is at, I get a non-zero alpha component. But wherever the fill is not
> covered by the stroke, I get the color components set, but a zero alpha
> component. The picture it's supposed to draw (and does display because
> the viewer I'm using ignores the alpha channel) is in the screen capture
> below. The bytes associated with it are printed on the right, one can
> see in the series of quadlets, what I'm describing.
>
> This is using 1.8.0, so maybe it's a known bug that's been fixed since?

If you pass in a HDC to cairo, it always assumes that it's 24bpp, since 
it generally has no way of finding out accurately whether the alpha 
channel is valid, or whether there's any kind of useful bitmap storage 
attached at all (without doing a bunch of SelectObjects and the like). 
If you need to draw to an ARGB DIB, cairo has to create it (using 
cairo_win32_surface_create_with_dib).

The above sounds like the fill ignoring the alpha byte (or setting it to 
0), probably because it's using a GDI function to do the fill.  The 
stroke is handled by cairo/pixman though, and since it's an XRGB surface 
it can just write whatever it wants to the alpha byte (since we don't 
promise to leave it untouched).

     - Vlad