http://bugs.winehq.org/show_bug.cgi?id=14842
Summary: Graphics glitch in DAZ Studio - regression Product: Wine Version: unspecified Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: niels.emmersen@pkf-it.dk
Cursor and checkboxes are clearly faulty. Bisect leads back to this:
fd8746b43ce24e209dd22c0bb1a4fe3ea38720a6 is first bad commit commit fd8746b43ce24e209dd22c0bb1a4fe3ea38720a6 Author: Michael Karcher wine@mkarcher.dialup.fu-berlin.de Date: Sun Jun 29 13:30:01 2008 +0200
gdi32: Fix palette of 1bpp DIB in GetDIBits.
Windows always generates a black/white palette for 1 bit DIBs generated from DDBs. Copying from the current palette only takes place for color DDBs (not explicitly mentioned in MSDN), and only if depth equal (MSDN states it, explicitly).
:040000 040000 507639edcf625253b7d9a2c63ea437adae1d980e f92463cfcde544b90d062fc1218883679b27cd57 M dlls
http://bugs.winehq.org/show_bug.cgi?id=14842
Niels niels.emmersen@pkf-it.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@mkarcher.dialup.fu- | |berlin.de
http://bugs.winehq.org/show_bug.cgi?id=14842
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial Keywords| |regression Summary|Graphics glitch in DAZ |Graphics glitch in DAZ |Studio - regression |Studio
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2008-08-11 18:39:26 --- What Wine version? Please provide screenshot of the problem.
http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #2 from Niels niels.emmersen@pkf-it.dk 2008-08-12 01:38:53 --- I don't know the exact version when this started, but it's present on 1.1.2.
Checkboxes toggle between all-black and all grey.
The normal mouse cursor works, but the resize-left-right and resize-up-down cursors are black boxes. I can't take a screenshot of that.
It's possible to change to layout style in the program, and for some styles the checkboxes work. So that's a practical solution to that part of the problem I suppose.
http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #3 from Niels niels.emmersen@pkf-it.dk 2008-08-12 03:25:44 --- DAZ Studio is freely downloadable from
http://www.daz3d.com/i.x/software/studio/-/download?&_m=d
You have to register (also free) the get a serial, or you can't start the program. There are a couple of warnings and errors during installation, but it works fine nonetheless.
http://bugs.winehq.org/show_bug.cgi?id=14842
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.daz3d.com/i.x/sof | |tware/studio/- | |/download?&_m=d Keywords| |download Version|unspecified |1.1.2
http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #4 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-13 03:12:32 --- Status report.
The bug seems to hit quite early in program startup. There are CreateCursor calls, and both the AND mask as well as the XOR mask are completely filled with zeroes, resulting in creation of a black square cursor. Directly before, a call sequence like this happens:
hBmpXor = CreateBitmap(32,32,1,1,XorData) hDCXor = CreateCompatibleDC(ScreenDC) oldBmpXor = SelectObject(hDCXor,hBmpXor) GetDIBits(ScreenDC,hBmpXor,0,32,XorBits,XorBitmapInfo,0) DeleteObject(SelectObject(hDCXor,oldBmpXor)); DeleteDC(hDCXor)
and the same for the AND mask. I currently don't have any more time to spare to trace it further (as I am just a hobbyist regarding to wine hacking) until weekend, but I suspect that XorData in the call to CreateBitmap is still correct, but the XorBits we get out of GetDIBits is wrong, especially as my commit that caused the regression is about GetDIBits.
If somebody else wants to track it, I would a) Check that XorData is correct b) Check that the pixmap created really contains two different colors c) Check that XorBits on the output is correct.
One of these step should fail, probably c). It is a bit difficult to reason about dataflow though, as the program seems to be copying data from one temporary heap buffer to other temporary heap buffers like mad, so you won't find the pointers like XorData or XorBits in any other API calls in the log except for HeapAlloc and HeapFree.
http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #5 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-16 06:32:48 --- The identified commit was not the real culprit. It happened to expose a problem in winex11.drv, which I tried to fix at the same time. Alas, that fix was wrong and did not apply in all cases it was needed in, and even might cause further damage in other cases. The (hopefully) real fix has been sent to wine-patches right now, see: http://www.winehq.org/pipermail/wine-patches/2008-August/059497.html
http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #6 from Niels niels.emmersen@pkf-it.dk 2008-08-16 06:43:44 --- Thanks again, I appreciate your efforts.
To correct myself, one can use (and so test) the program without a valid serial. I don't know how much functionality is available in this mode.
http://bugs.winehq.org/show_bug.cgi?id=14842
Niels niels.emmersen@pkf-it.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #7 from Niels niels.emmersen@pkf-it.dk 2008-08-22 13:16:49 --- This is fixed in 1.1.3, so I'm closing it.
http://bugs.winehq.org/show_bug.cgi?id=14842
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2008-09-05 10:39:37 --- Closing bugs fixed in 1.1.4.
-
wine-bugs＠winehq.org