Wow, thanks for all the bug fixes =)
I've committed changes to CVS that should cover everything but this one.. If
you don't mind double checking things, that'd be great.
As for this fix, I'd like to see it as a patch against CVS instead of a full
file. The way to do this, using the command line tool 'cvs' that comes with
wincvs, is to run 'cvs diff -ud > ..\freeamp.diff' from the base freeamp
directory you've been working in.
That'll get it into the format that I prefer when applying things...
Thanks, and I appreciate the work =)
On 10-Jan-2001 Jason Slater wrote:
> 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
> may use different formats to store data, only the device knows its
> 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
> 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..
E-Mail: Isaac Richards <[EMAIL PROTECTED]>
This message was sent by XFMail