[cairo] Weird fill vs stroke behavior on Windows
Vladimir Vukicevic
vladimir at pobox.com
Mon Mar 30 21:49:54 PDT 2009
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
More information about the cairo
mailing list