[Bug 885] Screen Corruption in riven
Wine Bugs
wine-bugs at winehq.com
Fri Jun 20 08:03:59 CDT 2003
http://bugs.winehq.com/show_bug.cgi?id=885
------- Additional Comments From z_god at wanadoo.nl 2003-20-06 08:03 -------
Bug comments restored from Gmane.org:
When playing Riven I can move ahead and the screens are fine, but when I want to
rotate the view the screen gets corrupted. I think I have tracked the problem
down to StretchBlt and BitBlt in X11, but I have run into problems debugging it.
It turns out that winedbg uses BITBLT_InternalStretchBlt extensivly so I cannot
use winedbg to track down.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16
23:19 -------
Created an attachment (id=228)
--> (http://bugs.winehq.com/attachment.cgi?id=228&action=view)
Screen shot before rotate.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16
23:21 -------
Created an attachment (id=229)
--> (http://bugs.winehq.com/attachment.cgi?id=229&action=view)
Screen shot after rotate
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16
23:22 -------
Created an attachment (id=230)
--> (http://bugs.winehq.com/attachment.cgi?id=230&action=view)
Screenshot of what it should look liek after rotate.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16
23:26 -------
Created an attachment (id=231)
--> (http://bugs.winehq.com/attachment.cgi?id=231&action=view)
Short log file that goes with screen shots
------- Additional Comments From dclark <at> akamail.com 2002-07-17 11:32 -------
Yep, I agree. I noticed that by setting transitions to "best", it becomes really
obvious what is happening. It is supposed to scroll the window left or right,
and then paints in the new portion of the display. It does it with calls like this:
trace:scroll:X11DRV_ScrollDC 08dc -181,0 hrgnUpdate=0000 rcUpdate = (nil)
which as you suggest causes a BitBlt:
trace:bitblt:BitBlt hdcSrc=08dc 181,0 24 bpp->hdcDest=08dc 0,0 427x392x24
rop=cc0020
For some reason, that does not seem to be working. Only the new part is being
painted in. The scroll never happens. I never got much beyond that point.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18
12:25 -------
:BitBlt hdcSrc=08dc 181,0 24 bpp->hdcDest=08dc 0,0 427x392x24 rop=cc0020
OK. This looks (to me) like the source and destination are the same. hdcSrc and
hdcDest both = 08dc. Based on my experience with SimCity's screen corruption I
am inclined to be suspicious of this. The other thing about it is that it is
24bpp and as Lionel says its evil <g>
source x = 181
source y = 0
destination x = 0
destination y = 0
width = 427
hieght = 392
So my assumption is that you clicked on the right side of the screen and the
left hand side of the screen is not getting updated, right?
------- Additional Comments From dclark <at> 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.
------- Additional Comments From tony_lambregts <at> 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?
------- Additional Comments From dclark <at> 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).
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18
23:30 -------
It's a timing problem, it seems that when the source and destination are the
same the screen is not updated properly before the next bitblt. I found this out
by putting a FIXME in a for loop. I wanted to slow this down so I could see the
problem as it progressed. What it did is clear the problem up.
....
physDevDst->exposures++;
wine_tsx11_unlock();
if (physDevDst == physDevSrc){
INT q;
for(q=1;q<1000 q++){
FIXME("Same Source;
}
}
return TRUE;
....
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-19
02:50 -------
Created an attachment (id=235)
--> (http://bugs.winehq.com/attachment.cgi?id=235&action=view)
Horribly hacked solution that masks the problem (patch)
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-19
21:13 -------
Duane, have you tried Riven with either of my hacks and if so what do you think
the problem is? Do you have any idea how to really fix this or should we leave
it to one of the real wine guru's?
------- Additional Comments From dclark <at> akamail.com 2002-07-20 11:38 -------
I tried both. They partially fix it for me, but not completely. I still get a
single piece of the old view, though it is a much smaller piece than before. It
always happens if I first move forward and then turn sideways. And of course the
other noticable thing is that the window does not slide (scroll) but instead
just jumps from one view to the other.
I notice that if I obscure part of the window with another window and then
uncover it, that it is repainted with the corruption still there. By the way, I
can always get the window to repaint correctly by sliding my mouse down into the
area at the bottom where the books are kept. This might require the window focus
to be set to focus follows mouse.
I don't really have much of a feel for where the problem is. It appears to me
that the bitblt commands have the correct parameters, so like you I think this
is some sort of timing problem. I have the Xlib reference book that explains the
XCopyArea command, but it does not mention any gotchas if the two Drawables are
the same. At the point I don't think I now enough to know how to attack it.
------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-24
18:42 -------
I've had several days to think about this one and I have come up with the
following conclusions
1. The problem is not with the source and destination drawables being the same.
This is pretty rock stable stuff that has been tested in X11 for years. Also
while Debuging Bug 792 I noticed that when scrolling in the file dialog that
the source and destination were the same with no screen corruption. (I had put a
fixme in the code to detect this.) So it isn't this.
2. Timing is a factor because slowing down the execution of same drawables
clears up the problem somewhat.
3. If I move forward and then turn. at the begining of the trace there is this
fixme.
> fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
This does not occure if I am turning around in circles. What brought my
attention to this is that another program that has screen corruption (Bug 911)
displays this fixme a lot.
All that means is that I understand the problem a little better and have a hint
of where to look next I suppose. My burning question at this point is what does
the somewhat cryptic fixme really mean?
------- Additional Comments From dclark <at> akamail.com 2002-07-25 13:00 -------
I think that slowing down redrawing is actually masking the problem, rather than
fixing it somewhat. I noticed that what Riven appears to do is measure how long
it takes to perform a scroll, and if it is too long, Riven does fewer scrolls
with larger chunks. I think this is what it is doing what it initially does
several zero length scrolls. And specifically, what makes it appear to work is
that if scrolling takes really long, it does the scroll in a single step. Since
the painting of the fill image has always worked, if the fill image is the
entire thing, it appears to work.
So in short, I am less confident now that it really is a timing issue.
------- Additional Comments From dclark <at> akamail.com 2003-01-09 14:18 -------
Fixed by:
http://www.winehq.com/hypermail/wine-cvs/2003/01/0159.html
------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-01-09
19:16 -------
Closing... Thanks Duane.
--
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the wine-bugs
mailing list