New subject: [Bug 10112] BitBlt between 8 bit color index DIBs wrong

20 Oct 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@winehq.org
        ReportedBy: alexd14@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.

[Bug 10112] New: BitBlt between 8 bit color index DIBs wrong