Avoid DrawDibDraw corruption with SetStretchBltMode

[Match Mover]

Patch by Russ Andersson, matchmovie at yahoo.com vws 12/3/04 WineHQ web CVS.
Please CC direct to me re disposition, tnx.

DrawDibDraw indirectly generates major artifacts when an image is being
shrink'd smaller, because the resulting StretchBlt executes using the DC's
default BlackOnWhite mode. In short, if you are shrinking by a factor of 4,
then each 4 source pixels values are logic-ANDed together to form the resulting
pixel. If, for example, the values are a small ramp, 0x7e,0x7f,0x80,0x81, the
output pixel is 0---there aren't any bits that are a 1 in all 4 pixels!
(anything 0x7e-0x81 would be OK). BlackOnWhite is a bad mode for paletted and
for RGB images, it is appropriate only for 1-bit black/white images.

I have confirmed that in WinXP, DrawDibDraw performs a SetStretchBltMode to
COLORONCOLOR, which would cause every 4th pixel to be selected in the example.
I'm using CodeWeavers CrossOffice, so I'm not able to test the patch. To
minimize potential impact, the mode is left unchanged if the destination HDC is
a one-bit HDC for which BLACKONWHITE would be appropriate, though I do not know
what WinXP does---it might set the mode unconditionally, for example.

Thanks,
Russ

--- drawdib.c	2004-12-03 09:03:50.754811840 -0500
+++ drawdib1.c	2004-12-03 09:07:45.648102632 -0500
@@ -369,6 +369,8 @@
          SelectPalette(hdc, whdd->hpal, FALSE);
     }
 
+    if (lpbi->biBitCount != 1)
+	SetStretchBltMode(whdd->hdc, COLORONCOLOR);
     if (!(StretchBlt(whdd->hdc, xDst, yDst, dxDst, dyDst, whdd->hMemDC, xSrc,
ySrc, dxSrc, dySrc, SRCCOPY)))
         ret = FALSE;
     



		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo