this bug occurs on some machines that have "buggy" video drivers --
it deals with the GetDIBits Win32 function, which, according to MS
docs, cannot be trusted to work 100%.
I quote from http://support.microsoft.com/support/kb/articles/Q74/6/01.ASP
"GetDIBits is performed on the device driver level. Because different
devices
may use different formats to store data, only the device knows its
particular
format. Thus, it is the responsibility of the driver to convert the device
format to a device-independent format. If the device driver is not
completely
reliable, then GetDIBits may return erroneous information. This should be
considered when using GetDIBits. "
The function I've rewritten parts of is:
void Win32Bitmap::CreateMaskBitmap(void)
it was calling GetDIBits for each line of a bitmap, getting a line,
parsing it for transparency colors, and setting the mask bitmap bits
accordingly. This normally shouldn't be an issue, but I noticed
different behavior on my laptop vs. my home box which is running
Win2k on a Matrox Millennium G200 (very mainstream card). The code
was allocating (correctly) a line-sized buffer to receive a line of
the bitmap bits, yet the video driver was returning the entire set
of bits -- badly overrunning the allocated buffer. I went and
downloaded a newer, "certified" ;-), driver from Matrox ..
installed it ... and still no dice.
So, I rewrote the code to grab the bitmap bits all at once, into a
properly sized buffer, parse thru it all, and write the correct bits
back to the mask bitmap. Works like a charm on both my systems.
Documented the code in case you wanted to make sure all is up to snuff.
Should even be a tad faster, since old code did 2 GDI API calls per
line of bitmap, and this does only two calls per bitmap.
I still need to go through the function:
HRGN Win32Canvas::GetMaskRgn(void)
as there is similar behavior here as well..
-Jason
Win32Bitmap.cpp
