[Bug 10112] New: BitBlt between 8 bit color index DIBs wrong
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Oct 20 06:27:24 CDT 2007
http://bugs.winehq.org/show_bug.cgi?id=10112
Summary: BitBlt between 8 bit color index DIBs wrong
Product: Wine
Version: CVS/GIT
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-x11driver
AssignedTo: wine-bugs at winehq.org
ReportedBy: alexd14 at hushmail.com
Created an attachment (id=8678)
--> (http://bugs.winehq.org/attachment.cgi?id=8678)
test case
BitBlt from one 8 bit DIB to another 8 bit DIB produces wrong results. I'll
attach a simple test case that illustrates the problem. What it does: creates
two 8 bit, color index dib sections with a color table where color index 1 =
red, 2 = blue, 3 = green. Then it fills first DIB with 1 (red) and second with
2 (blue). It then does a BitBlt with SRCPAINT (OR) ROP from first DIB to
second. Finally, this DIB is drawn in a window, and a hex value of the first
pixel is drawn over it for convenience.
In such BitBlt Windows, apparently, operates on DIB pixels as color index
values w/o palette lookup; 1 OR 2 == 3, so it fills destination DIB pixels with
3, and, consequently, it is displayed as a green rectangle.
In Wine, this operation works like actual RGB values (red and blue) from
palettes are getting combined, and it's displayed as a magenta rectangle.
Probably, because wine seems to convert it to truecolor pixmaps internally.
Pixels as stored in memory become zeros.
Real app affected by it: igonwin.exe in bug #201
(http://bugs.winehq.org/show_bug.cgi?id=201). I don't have other apps that use
color index dibs to test, but I think any apps that use such DIBs AND "fancy"
ROPs (XOR, AND, OR etc) may be affected.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list