http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From dclark(a)akamail.com 2002-07-18 22:56 -------
Yep, it looks like that for me. I added a trace to check the parameters to
XCopyArea, and they look ok.
case SRCCOPY: /* 0xcc */
if (dcSrc->bitsPerPixel == dcDst->bitsPerPixel)
{
TRACE(" src_xy=%d,%d size=%d,%d dst_xy=%d,%d\n",
physDevSrc->org.x + visRectSrc.left,
physDevSrc->org.y + visRectSrc.top,
width, height,
physDevDst->org.x + visRectDst.left,
physDevDst->org.y + visRectDst.top );
I think what is happening is that the first bitblt is doing the scroll on an
internal image.
trace:bitblt:BitBlt hdcSrc=08dc 38,0 24 bpp->hdcDest=08dc 0,0 570x392x24 rop=cc0020
...
trace:bitblt:BITBLT_InternalStretchBlt src_xy=38,0 size=570,392 dst_xy=0,0
And then the second copies the entire image to the screen
trace:bitblt:StretchBlt 08dc 0,0 608x392x24 -> 0894 0,0 608x392x24 rop=cc0020
...
trace:bitmap:X11DRV_DIB_SetImageBits
XPutImage(44041069,0x8079818,0x80b3ec0,0,0,0,0,608,436)
...
trace:bitblt:BITBLT_InternalStretchBlt src_xy=0,0 size=608,392 dst_xy=16,22
The dst_xy on this second one is offset to accomodate the frame (I think).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-18 19:47 -------
Well I've tracked it down to this code snippet
case SRCCOPY: /* 0xcc */
if (dcSrc->bitsPerPixel == dcDst->bitsPerPixel)
{
wine_tsx11_lock();
XSetFunction( gdi_display, physDevDst->gc, GXcopy );
XCopyArea( gdi_display, physDevSrc->drawable,
physDevDst->drawable, physDevDst->gc,
physDevSrc->org.x + visRectSrc.left,
physDevSrc->org.y + visRectSrc.top,
width, height,
physDevDst->org.x + visRectDst.left,
physDevDst->org.y + visRectDst.top );
physDevDst->exposures++;
wine_tsx11_unlock();
return TRUE;
}
In each case it goes into this code. (XCopyArea is not a wine function)
can you confirm?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=502
------- Additional Comments From mstefani(a)redhat.com 2002-07-18 18:11 -------
Patch sent to wine-patches.
I would assign this bug to me, but it seems I can't do it.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=502>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From dclark(a)akamail.com 2002-07-18 17:48 -------
Yep, that was a click on the right. And of course there is a series of quick
scrolls of various sizes, corresponding to the various sized pieces left on the
right side causing the screen corruption.
trace:scroll:X11DRV_ScrollDC 08dc -181,0 hrgnUpdate=0000 rcUpdate = (nil)
trace:scroll:X11DRV_ScrollDC 08dc -81,0 hrgnUpdate=0000 rcUpdate = (nil)
trace:scroll:X11DRV_ScrollDC 08dc -81,0 hrgnUpdate=0000 rcUpdate = (nil)
trace:scroll:X11DRV_ScrollDC 08dc -82,0 hrgnUpdate=0000 rcUpdate = (nil)
trace:scroll:X11DRV_ScrollDC 08dc -60,0 hrgnUpdate=0000 rcUpdate = (nil)
I think 24 bits is only because that is what my video card is set for, so that
is what wine is using. Riven itself is only 8 bit color, as I recall.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=885>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=882
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-18 17:30 -------
My profuse appologies for my spelling.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=882>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=882
------- Additional Comments From andi(a)rhlx01.fht-esslingen.de 2002-07-18 16:38 -------
It's NOT pallet !
For some reason I hate it when people can't spell palette properly
(and thus even mention a non-existing debugmsg at the same time).
(that's quite appallETing, to be exact :-)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=882>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=882
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-18 16:28 -------
If you think its a pallet problem then you should try --debugmsg +pallet to see
what you can find. Attach the relevent portion of the trace to this bug. You
might find the following patch helpfull for pinpointing problems.
Index: dlls/x11drv/mouse.c
===================================================================
RCS file: /home/wine/wine/dlls/x11drv/mouse.c,v
retrieving revision 1.8
diff -u -r1.8 mouse.c
--- dlls/x11drv/mouse.c 14 Jun 2002 00:08:40 -0000 1.8
+++ dlls/x11drv/mouse.c 18 Jul 2002 21:23:22 -0000
@@ -544,6 +544,7 @@
update_cursor( hwnd, event->window );
get_coords( &hwnd, event->window, event->x, event->y, &pt );
+ FIXME("\tx:=%d y:=%d ----------------------\n",event->x,event->y);
switch (buttonNum)
{
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=882>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=882
------- Additional Comments From johane(a)lysator.liu.se 2002-07-18 15:07 -------
In the gameplay, the blue background colour used in the game menu is way too
dark. It's not a monitor issue, so I say we have a palette problem on our hands.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=882>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=878
------- Additional Comments From tony_lambregts(a)telusplanet.net 2002-07-18 14:28 -------
I must check if the background of my window manager is black. (SawFish)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=878>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://bugs.winehq.com/show_bug.cgi?id=878
------- Additional Comments From us(a)the-edmeades.demon.co.uk 2002-07-18 13:38 -------
Hmmm - Sounds like I am one step ahead of you!! No idea really - The
background of the icon should be the same colour as the active window title
bar (in my case blue). The only reason I tried playing with managed is that
the X11drv part of icons has special code in one of the cases.
I am running Mandrake 8.2 if it helps, cant remember what window manager though
(I dual boot, am in windows right now...)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://bugs.winehq.com/show_bug.cgi?id=878>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.