http://bugs.winehq.org/show_bug.cgi?id=20164
Summary: Regression : Icons incorrectly rendered in RSTAB Product: Wine Version: 1.1.30 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: max@veneto.com CC: thunderbird2k@gmail.com
Created an attachment (id=23761) --> (http://bugs.winehq.org/attachment.cgi?id=23761) Bad (above) and correct (below) behaviour of icons in RSTAB toolbar
this patch :
http://source.winehq.org/git/wine.git/?a=commit;h=004eabfbd398192c0de92bafe1...
caused a regression in RSTAB application, as shown by attached image.
Commenting out XRender code here (in winex11.drv/bitblt.c around line 1440
[code] if (useSrc) { wine_tsx11_lock(); pixmaps[SRC] = XCreatePixmap( gdi_display, root_window, width, height, physDevDst->depth ); wine_tsx11_unlock();
// if(!X11DRV_XRender_GetSrcAreaStretch( physDevSrc, physDevDst, pixmaps[SRC], tmpGC, // widthSrc, heightSrc, widthDst, heightDst, // &visRectSrc, &visRectDst)) // { if (fStretch) BITBLT_GetSrcAreaStretch( physDevSrc, physDevDst, pixmaps[SRC], tmpGC, xSrc, ySrc, widthSrc, heightSrc, xDst, yDst, widthDst, heightDst, &visRectSrc, &visRectDst ); else BITBLT_GetSrcArea( physDevSrc, physDevDst, pixmaps[SRC], tmpGC, &visRectSrc ); // } }
[/code]
makes things working again.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmail.com 2009-09-26 07:07:26 --- Could you try if this patch which I need to resubmit fixes the issue: http://www.winehq.org/pipermail/wine-patches/2009-September/078446.html ?
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #2 from max@veneto.com 2009-09-26 07:18:31 --- (In reply to comment #1)
Could you try if this patch which I need to resubmit fixes the issue: http://www.winehq.org/pipermail/wine-patches/2009-September/078446.html ?
Sorry, your patch don't apply cleanly to current git, and I've got no time by now to fix it :-( Let me know if you rebase it to 1.1.30.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #3 from Roderick Colenbrander thunderbird2k@gmail.com 2009-09-26 07:54:57 --- Created an attachment (id=23769) --> (http://bugs.winehq.org/attachment.cgi?id=23769) Possible fix
Try this patch.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20164
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Severity|normal |trivial
http://bugs.winehq.org/show_bug.cgi?id=20164
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=20164
max@veneto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |normal
--- Comment #4 from max@veneto.com 2009-09-26 16:17:21 --- Nope, the patch doesn't fix the issue. The icons remembers me something when I was developing my dib engine, and it was related to mixed blitting between dib engine managed bitmaps and x11drv managed ones.....
Changing importance again to normal, I don't see anything trivial on that one.
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #5 from Roderick Colenbrander thunderbird2k@gmail.com 2009-09-26 17:09:02 --- What display drivers are you using? Basically I'm using XRender in this case for copying the data instead of plain xlib calls. It can also perform stretching and other operations. Perhaps it is something related to the 1-bit masking code.
You could try to look at the xrender function. You'll see two codepaths: /* mono -> color */ if(physDevSrc->depth == 1) ... else /* color -> color but with different depths */ ...
First figure out in which codepath it goes wrong e.g. by just returning false in the codepath, since then we will fall back to the old non-xrender code. If it is in the 1-bit code perhaps the wrong background color is used or so. Did this regression occur in 1.1.30 or did it occur earlier as well? Since I added X11DRV_XRender_GetSrcAreaStretch a couple of release ago.
Thanks, Roderick
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #6 from max@veneto.com 2009-09-26 17:28:57 --- (In reply to comment #5)
...... Did this regression occur in 1.1.30 or did it occur earlier as well? Since I added X11DRV_XRender_GetSrcAreaStretch a couple of release ago.
Thanks, Roderick
Hi Roderick,
the regression occurred exactly on the patch pointed on the bug report. I didn't notice before because I was using an old build on these days... no time to test new releases because of my job :-( Anyways, I just updated, noticed the regression and made a regression testing from 1.1.19 to 1.1.30, which pointed me to your patch. I can't test more in depth right now, I hope I'll have more time on next days...
I stumbled over a similar problem when I was developing the DIB engine using the old approach of the mixed pysdev pointers some months ago, and (IIRC) it was due to mixed blt's between dib engine managed stuff and x11drv ones. If you look at icons, you can see that some of them are just slightly shifted, others are completely wrong, so I guess your source bitmap used in blitting is wrong somehow. My (old) similar problem was because (IIRC) x11drv has an internal PIXMAP copy of DIB, (in some kind of linked list ? don't remember...) which was not there on DIBs managed by my engine. On mixed blitting winex11.drv was reading the (non-existent) pixmap internal copy instead of the true dib content, which was of course not the desired effect..... BTW, that's the main reason because my engine is slower than original on mixed blits; it must convert dib to ddb and pass it to winex11, as using DIB directly doesn't work because of the missing internal PIXMAP buffer.
Ah, obviously I tested it on vanilla wine, without my engine, to be sure it was not due to it :-) About RSTAB, there is a demo on www.dlubal.com, but now it's on 7.xx version and I'm using the 5.xx one.... don't know if bug is present on new one.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial
--- Comment #7 from Vitaliy Margolen vitaliy@kievinfo.com 2009-09-26 22:05:51 --- Trivial - For a UI glitch that doesn't affect running of a program http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=20164
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch |
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2009-09-26 22:06:07 --- There is no working patch
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #9 from max@veneto.com 2009-09-27 03:29:52 --- (In reply to comment #7)
Trivial - For a UI glitch that doesn't affect running of a program http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
Normal For an application crash or loss of functionality
If you call "ui glitch only" completely scrambled icons that makes the app unusable (many commands are available only with toolbar) then, ok, is trivial. Then I'd call 'trivial' also something that makes screen appear completely black, program still runs.....
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression : Icons |Icons incorrectly rendered |incorrectly rendered in |in RSTAB |RSTAB |
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #10 from Roderick Colenbrander thunderbird2k@gmail.com 2009-09-27 05:48:12 --- Version 7 doesn't have the issue. If you can please analyze the code a bit and figure out where it goes wrong. In short all the function does is copying data from a source pixmap (which has an associated xrender picture) to a destination. Either something is wrong with masking or perhaps as you say with offsets.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #11 from max@veneto.com 2009-10-13 18:03:05 --- (In reply to comment #10)
Version 7 doesn't have the issue. If you can please analyze the code a bit and figure out where it goes wrong. In short all the function does is copying data from a source pixmap (which has an associated xrender picture) to a destination. Either something is wrong with masking or perhaps as you say with offsets.
Roderick
Just adding some fixme printouts, it repeats this pattern :
fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------- START ---------------------- trace:xrender:X11DRV_XRender_GetSrcAreaStretch src depth=24 widthSrc=176 heightSrc=15 xSrc=0 ySrc=0 trace:xrender:X11DRV_XRender_GetSrcAreaStretch dst depth=1 widthDst=176 heightDst=15 xDst=0 yDst=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------Depth of no use
-------- SOME USELESS STUFFS -------
fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------- START ---------------------- trace:xrender:X11DRV_XRender_GetSrcAreaStretch src depth=1 widthSrc=16 heightSrc=15 xSrc=0 ySrc=0 trace:xrender:X11DRV_XRender_GetSrcAreaStretch dst depth=24 widthDst=16 heightDst=15 xDst=0 yDst=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------Converting mono to color fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------END trace:xrender:get_xrender_format Returning wxr_format=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------- START ---------------------- trace:xrender:X11DRV_XRender_GetSrcAreaStretch src depth=1 widthSrc=16 heightSrc=15 xSrc=16 ySrc=0 trace:xrender:X11DRV_XRender_GetSrcAreaStretch dst depth=24 widthDst=16 heightDst=15 xDst=16 yDst=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------Converting mono to color fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------END trace:xrender:get_xrender_format Returning wxr_format=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------- START ---------------------- trace:xrender:X11DRV_XRender_GetSrcAreaStretch src depth=1 widthSrc=16 heightSrc=15 xSrc=32 ySrc=0 trace:xrender:X11DRV_XRender_GetSrcAreaStretch dst depth=24 widthDst=16 heightDst=15 xDst=32 yDst=0 fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------Converting mono to color fixme:xrender:X11DRV_XRender_GetSrcAreaStretch ----------------END
and so on.... So, it seems it takes a very wide bitmap (presumably containing many icons in an horizontal strip, in 24 bit/color, convert to a 1bpp, and then uses the 1bpp to output the single icons. The 24 to 1 conversion is not handled by your code, the 1 to 24 are... maybe the problem lies there.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #12 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-13 18:28:36 --- Hi Max,
If you suspect that this 24->1 is the issue, you could make that case fail and just return FALSE. When FALSE is returned the code reverts to the old non-xrender code path. If it works then, then you know for certain that it is related to that specific code path.
Such a test would be useful.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #13 from max@veneto.com 2009-10-14 09:27:29 --- (In reply to comment #12)
Hi Max,
If you suspect that this 24->1 is the issue, you could make that case fail and just return FALSE. When FALSE is returned the code reverts to the old non-xrender code path. If it works then, then you know for certain that it is related to that specific code path.
Such a test would be useful.
Roderick
Yep, I didn't think about it.... I made the test and it's indeed the problem. Returning false on the 24->1 conversion renders icons correctly.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #14 from Wylda wylda@volny.cz 2009-11-16 18:30:07 --- Created an attachment (id=24796) --> (http://bugs.winehq.org/attachment.cgi?id=24796) Incorectly rendered icons
Hi, nearly two months past, nothing changed = i.e. still not fixed in current git (wine-1.1.33-88-gd51b4e1) and there is another bug 20732, which in comment #0 contains tiny example application written as a test even with source code.
bisecting showed me commit:
004eabfbd398192c0de92bafe1b31381a07d7a9c is first bad commit commit 004eabfbd398192c0de92bafe1b31381a07d7a9c Author: Roderick Colenbrander thunderbird2k@gmail.com Date: Thu Jul 9 21:20:12 2009 +0200
winex11: Add an XRender based GetSrcAreaStretch.
:040000 040000 8eb47f001f4635ac2ebb31c451b0bd5b46b11c78 ee9832dcd1175a51ccaca17f92674b3507a1be1d M dlls
http://bugs.winehq.org/show_bug.cgi?id=20164
Gabriele Moabiti gabmoa@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabmoa@yahoo.it
http://bugs.winehq.org/show_bug.cgi?id=20164
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #15 from Wylda wylda@volny.cz 2009-11-16 18:52:08 ---
Because the bug is between 1.1.25 and 1.1.26, version should be changed to 1.1.26, shouldn't be?
--private keyword: bisected
http://bugs.winehq.org/show_bug.cgi?id=20164
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.30 |1.1.26
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #16 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-17 10:33:51 --- The RSTAB bug might be fixed in GIT now.
http://bugs.winehq.org/show_bug.cgi?id=20164
--- Comment #17 from Nikolay Sivov bunglehead@gmail.com 2010-05-24 06:17:47 --- Please test with 1.2-rc1.
http://bugs.winehq.org/show_bug.cgi?id=20164
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Regression SHA1| |004eabfbd398192c0de92bafe1b | |31381a07d7a9c
http://bugs.winehq.org/show_bug.cgi?id=20164
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |00cpxxx@gmail.com Resolution| |FIXED
--- Comment #18 from Bruno Jesus 00cpxxx@gmail.com 2012-04-07 11:38:32 CDT --- This bug has been fixed some months ago with several other toolbar/icons background problem. Retested in wine 1.5.
Needs winetricks mfc40 vb6run mfc42 prior to the program installation.
If anyone can retest and still can reproduce the issue feel free to reopen.
http://bugs.winehq.org/show_bug.cgi?id=20164
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2012-04-13 13:27:46 CDT --- Closing bugs fixed in 1.5.2.