Hallo, Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc <mstefani(a)redhat.de>, but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Uwe Bonnes wrote:
Hallo,
Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc <mstefani(a)redhat.de>, but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap
The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background.
I have seen similar symptoms in other applications, all of which used to be fine. In one case, the background shifts through interesting psychedelic colors as I move the mouse around, so I did not necessarily consider this a bug :-) I found that the patch that broke it was one of the comctrl patches of 9/11/02. I think it was this one: http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html I figured since Dimitri was still going strong on this comctrl stuff (does he ever sleep?), it would eventually get fixed.
On October 12, 2002 01:29 pm, Duane Clark wrote:
I found that the patch that broke it was one of the comctrl patches of 9/11/02. I think it was this one: http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html
I thought that was the case, but I can not reproduce it here.... Can you try the patch below and (1) tell me if that fixes it, and if not, can you send me the generated trace?
I figured since Dimitri was still going strong on this comctrl stuff
I don't want to be pedantic, but not to be confused with Dmitry, but I'm either Dimitrie, or Dimi, for short. :)
(does he ever sleep?), it would eventually get fixed.
Truth be told, I had some problems sleeping lately... :/ Today is g/f day, so I can't spend time on this, and tomorrow is Thanks Giving here in Canada, so I can't spend too much time on these for the next little while, but I'll surely appreciate if you can try this above mentioned patch: Index: dlls/comctl32/imagelist.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.61 diff -u -r1.61 imagelist.c --- dlls/comctl32/imagelist.c 24 Sep 2002 18:26:42 -0000 1.61 +++ dlls/comctl32/imagelist.c 12 Oct 2002 23:43:12 -0000 @@ -1078,6 +1078,11 @@ if (!pimldp || !himl) return FALSE; if ((pimldp->i < 0) || (pimldp->i >= himl->cCurImage)) return FALSE; + ERR("(himl=%p, cbSize=%ld hbmMask=0x%08x iImage=%d x=%d y=%d" + " cx=%d cy=%d rgbBk=0x%08lx rgbFg=0x%08lx fStyle=0x%08x)\n", + himl, pimldp->cbSize, himl->hbmMask, pimldp->i, pimldp->x, pimldp->y, + pimldp->cx, pimldp->cy, pimldp->rgbBk, pimldp->rgbFg, pimldp->fStyle); + fState = pimldp->cbSize < sizeof(IMAGELISTDRAWPARAMS) ? ILS_NORMAL : pimldp->fState; fStyle = pimldp->fStyle & ~ILD_OVERLAYMASK; cx = (pimldp->cx == 0) ? himl->cx : pimldp->cx; @@ -1086,9 +1091,6 @@ bIsTransparent = himl->hbmMask && ((fStyle & ILD_TRANSPARENT) || clrBk == CLR_NONE); bBlend = fStyle & (ILD_BLEND25 | ILD_BLEND50); - TRACE("hbmMask(0x%08x) iImage(%d) x(%d) y(%d) cx(%d) cy(%d)\n", - himl->hbmMask, pimldp->i, pimldp->x, pimldp->y, cx, cy); - /* we will use these DCs to access the images and masks in the ImageList */ hImageListDC = CreateCompatibleDC(0); hMaskListDC = himl->hbmMask ? CreateCompatibleDC(0) : 0; @@ -1115,11 +1117,13 @@ oldImageFg = SetTextColor( hImageDC, RGB( 0, 0, 0 ) ); oldImageBk = SetBkColor( hImageDC, RGB( 0xff, 0xff, 0xff ) ); +ERR("himl=%p: A\n", himl); /* If we have an opaque image, draw the background */ if (!bIsTransparent && himl->hbmMask) { HBRUSH hOldBrush = SelectObject (hImageDC, CreateSolidBrush (clrBk)); PatBlt( hImageDC, 0, 0, cx, cy, PATCOPY ); DeleteObject (SelectObject (hImageDC, hOldBrush)); +ERR("himl=%p: B\n", himl); } /* @@ -1127,18 +1131,22 @@ */ if(fStyle & ILD_MASK) { if (himl->hbmMask) { +ERR("himl=%p: C\n", himl); BitBlt(hImageDC, 0, 0, cx, cy, hMaskListDC, lx, ly, SRCCOPY); } else { HBRUSH hOldBrush = SelectObject (hImageDC, GetStockObject(BLACK_BRUSH)); PatBlt( hImageDC, 0, 0, cx, cy, PATCOPY); SelectObject(hImageDC, hOldBrush); +ERR("himl=%p: D\n", himl); } } else if (himl->hbmMask) { +ERR("himl=%p: E\n", himl); BitBlt( hImageDC, 0, 0, cx, cy, hMaskListDC, lx, ly, SRCAND ); BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCPAINT ); } else { /* the image is opaque, just copy it */ TRACE(" - Image is opaque\n"); +ERR("himl=%p: F\n", himl); BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCCOPY); } @@ -1149,6 +1157,7 @@ HDC hBlendMaskDC = hImageListDC; HBITMAP hOldBitmap; +ERR("himl=%p: G\n", himl); /* Create the blend Mask */ hOldBitmap = SelectObject(hBlendMaskDC, hBlendMaskBmp); hBlendBrush = fStyle & ILD_BLEND50 ? himl->hbrBlend50 : himl->hbrBlend25; @@ -1158,13 +1167,16 @@ /* Modify the blend mask if an Image Mask exist */ if(himl->hbmMask) { +ERR("himl=%p: H\n", himl); BitBlt(hBlendMaskDC, 0, 0, cx, cy, hMaskListDC, lx, ly, 0x220326); /* NOTSRCAND */ BitBlt(hBlendMaskDC, 0, 0, cx, cy, hBlendMaskDC, 0, 0, NOTSRCCOPY); } /* now apply blend to the current image given the BlendMask */ +ERR("himl=%p: I, clrBlend=0x%08lx\n", himl, clrBlend); if (clrBlend == CLR_DEFAULT) clrBlend = GetSysColor (COLOR_HIGHLIGHT); else if (clrBlend == CLR_NONE) clrBlend = GetTextColor (pimldp->hdcDst); +ERR("himl=%p: J, clrBlend=0x%08lx\n", himl, clrBlend); hOldBrush = (HBRUSH) SelectObject (hImageDC, CreateSolidBrush(clrBlend)); BitBlt (hImageDC, 0, 0, cx, cy, hBlendMaskDC, 0, 0, 0xB8074A); /* PSDPxax */ DeleteObject(SelectObject(hImageDC, hOldBrush)); @@ -1177,8 +1189,12 @@ nOvlIdx = himl->nOvlIdx[nOvlIdx - 1]; if ((nOvlIdx >= 0) && (nOvlIdx < himl->cCurImage)) { const INT ox = himl->cx * nOvlIdx + pimldp->xBitmap; +ERR("himl=%p: K\n", himl); if (himl->hbmMask && !(fStyle & ILD_IMAGE)) + { +ERR("himl=%p: L\n", himl); BitBlt (hImageDC, 0, 0, cx, cy, hMaskListDC, ox, ly, SRCAND); + } BitBlt (hImageDC, 0, 0, cx, cy, hImageListDC, ox, ly, SRCPAINT); } } @@ -1197,12 +1213,13 @@ if (bIsTransparent && !(fStyle & ILD_MASK)) { COLORREF oldDstFg = SetTextColor(pimldp->hdcDst, RGB( 0, 0, 0 ) ); COLORREF oldDstBk = SetBkColor(pimldp->hdcDst, RGB( 0xff, 0xff, 0xff )); +ERR("himl=%p: M\n", himl); BitBlt (pimldp->hdcDst, pimldp->x, pimldp->y, cx, cy, hMaskListDC, lx, ly, SRCAND); SetBkColor(pimldp->hdcDst, oldDstBk); SetTextColor(pimldp->hdcDst, oldDstFg); dwRop = SRCPAINT; } - if (fStyle & ILD_ROP) dwRop = pimldp->dwRop; + /*if (fStyle & ILD_ROP) dwRop = pimldp->dwRop;*/ BitBlt (pimldp->hdcDst, pimldp->x, pimldp->y, cx, cy, hImageDC, 0, 0, dwRop); bResult = TRUE;
Dimitrie O. Paun wrote:
On October 12, 2002 01:29 pm, Duane Clark wrote:
I found that the patch that broke it was one of the comctrl patches of 9/11/02. I think it was this one: http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html
I thought that was the case, but I can not reproduce it here.... Can you try the patch below and (1) tell me if that fixes it, and if not, can you send me the generated trace?
Still there for me, at least on the one app I tried it on. These are the messages I get, pretty much just repeated a bunch. err:imagelist:ImageList_DrawIndirect (himl=0x42250c18, cbSize=68 hbmMask=0x000009cc iImage=0 x=11 y=14 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x42250c18: A err:imagelist:ImageList_DrawIndirect himl=0x42250c18: E err:imagelist:ImageList_DrawIndirect himl=0x42250c18: M err:imagelist:ImageList_DrawIndirect (himl=0x42250c18, cbSize=68 hbmMask=0x000009cc iImage=2 x=11 y=77 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x42250c18: A err:imagelist:ImageList_DrawIndirect himl=0x42250c18: E err:imagelist:ImageList_DrawIndirect himl=0x42250c18: M err:imagelist:ImageList_DrawIndirect (himl=0x42250408, cbSize=68 hbmMask=0x00000920 iImage=0 x=3 y=3 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x42250408: A err:imagelist:ImageList_DrawIndirect himl=0x42250408: E err:imagelist:ImageList_DrawIndirect himl=0x42250408: M ... err:imagelist:ImageList_DrawIndirect (himl=0x42250408, cbSize=68 hbmMask=0x00000920 iImage=3 x=72 y=3 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x42250408: A err:imagelist:ImageList_DrawIndirect himl=0x42250408: E err:imagelist:ImageList_DrawIndirect himl=0x42250408: M
I figured since Dimitri was still going strong on this comctrl stuff
I don't want to be pedantic, but not to be confused with Dmitry, but I'm either Dimitrie, or Dimi, for short. :)
Oops. Got it.
On October 12, 2002 08:50 pm, Duane Clark wrote:
Still there for me, at least on the one app I tried it on. These are the messages I get, pretty much just repeated a bunch.
err:imagelist:ImageList_DrawIndirect (himl=0x42250c18, cbSize=68 hbmMask=0x000009cc iImage=0 x=11 y=14 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x42250c18: A err:imagelist:ImageList_DrawIndirect himl=0x42250c18: E err:imagelist:ImageList_DrawIndirect himl=0x42250c18: M
Interesting. These are the same as the trace I get from control spy, which works: err:imagelist:ImageList_DrawIndirect (himl=0x40dc2368, cbSize=68 hbmMask=0x00000948 iImage=2 x=171 y=4 cx=0 cy=0 rgbBk=0xff000000 rgbFg=0xff000000 fStyle=0x00000000) err:imagelist:ImageList_DrawIndirect himl=0x40dc2368: A err:imagelist:ImageList_DrawIndirect himl=0x40dc2368: E err:imagelist:ImageList_DrawIndirect himl=0x40dc2368: M Can you please send me a screenshots of the images in question, before and after this patch: --- dlls/comctl32/imagelist.c.T0 Sun Oct 13 10:13:50 2002 +++ dlls/comctl32/imagelist.c Sun Oct 13 10:13:58 2002 @@ -1210,6 +1210,7 @@ /* now copy the image to the screen */ dwRop = SRCCOPY; + bIsTransparent = FALSE; if (bIsTransparent && !(fStyle & ILD_MASK)) { COLORREF oldDstFg = SetTextColor(pimldp->hdcDst, RGB( 0, 0, 0 ) ); COLORREF oldDstBk = SetBkColor(pimldp->hdcDst, RGB( 0xff, 0xff, 0xff )); -- Dimi.
Oops, it looks like I did not read Uwe's original post very well. It appears I am looking at something different. Sorry about steering this thread away. Dimitrie O. Paun wrote:
Can you please send me a screenshots of the images in question, before and after this patch:
Okay, here are three images. The first is taken with the original CVS patch in question backed out. The images look good. http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html The second is what I get with the CVS patch installed. Notice that both the big icons and the toolbar icons have artifacts. The third image is after your quickie transparent patch. Actually, that patch makes it a little easier to see what the artifacts are. Pretty clearly, the background of the "Design" icon contains the "Portal" icon. Similarly the backgrounds of the toolbar icons contain the images from the other toolbar icons. So it looks like perhaps an index is off somewhere.
Duane Clark wrote:
Oops, it looks like I did not read Uwe's original post very well. It appears I am looking at something different. Sorry about steering this thread away.
Dimitrie O. Paun wrote:
Can you please send me a screenshots of the images in question, before and after this patch:
Okay, here are three images. The first is taken with the original CVS patch in question backed out. The images look good. http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html
I just noticed a patch from Carlos over in wine-patches. Tried it out and that fixed my image artifacts.
"Dimitrie" == Dimitrie O Paun <dpaun(a)rogers.com> writes:
Dimitrie> On October 12, 2002 01:29 pm, Duane Clark wrote: >> I found that the patch that broke it was one of the comctrl patches >> of 9/11/02. I think it was this one: >> http://www.winehq.com/hypermail/wine-cvs/2002/09/0067.html Dimitrie> I thought that was the case, but I can not reproduce it Dimitrie> here.... Can you try the patch below and (1) tell me if that Dimitrie> fixes it, and if not, can you send me the generated trace? This drifted away from my original posting. I talked about _native_ comctl32 showing problems with bitmaps, and the behaviourt changes with the patch I mentioned in my original posting. Now we are talking about _builtin_ comctl32... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On October 13, 2002 07:27 am, Uwe Bonnes wrote:
This drifted away from my original posting. I talked about _native_ comctl32 showing problems with bitmaps, and the behaviourt changes with the patch I mentioned in my original posting.
I know, but somehow I have a gut feeling that there might be a problem with my patch as well, just as Duane pointed out. Worth investigating... -- Dimi.
On Fri, Oct 11, 2002 at 12:13:48PM +0200, Uwe Bonnes wrote: Content-Description: message body and .signature
Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc <mstefani(a)redhat.de>, but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap
The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background. Well, the only real changes in the patch are in windows/cursoricon.c and the move the implementation of ExtractAssociatedIcon16 to ExtractAssociatedIconA. The rest are only explicit handle conversions that were done implicitly before by the compiler. Could you please revert only the changes in windows/cursoricon.c and see it that fixes your problem?
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
participants (4)
-
Dimitrie O. Paun -
Duane Clark -
Michael Stefaniuc -
Uwe Bonnes