[Bug 3902] Unnormal slowness in Heroes 4 (X11DRV_BitBlt?)
Wine Bugs
wine-bugs at winehq.org
Tue Nov 29 02:00:28 CST 2005
http://bugs.winehq.org/show_bug.cgi?id=3902
------- Additional Comments From giulian2003 at hotmail.com 2005-29-11 02:00 -------
I am trying to solve this:
If i am correct, the problem appears in file bitblt.c, function X11DRV_BitBlt
and it has to do with this part of code:
sDst = X11DRV_LockDIBSection( physDevDst, DIB_Status_None, FALSE );
if (physDevDst != physDevSrc)
sSrc = X11DRV_LockDIBSection( physDevSrc, DIB_Status_None, FALSE );
.........
if (sDst == DIB_Status_AppMod) {
FIXME("potential optimization - client-side DIB copy\n");
}
X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE );
The problem appears only when you move the mouse icon over the game map or the
minimap in the upper right corner of the game window. I tried to debug it
with 'WINEDEBUG=+bitblt wine h4mod.exe' and it seems that Heroes keeps one
bitmap for the entire window, one for the big map and one for the minimap and
when you move the mouse cursor over the later two, it tries to do a
X11DRV_BitBlt from the map/minimap to the window bitmap, followed imediately by
a X11DRV_BitBlt from the mouse icon bitmap to the same region of the window
bitmap. In that case it tries to aquire 'DIB_Status_GdiMod' locking state on t
he destination but it finds it in 'DIB_Status_AppMod' state.
I looked in dib.c to understand what happens then, anyway, this is a piece of
code taken from X11DRV_CoerceDIBSection function:
case DIB_Status_AppMod:
TRACE("GdiMod requested in status AppMod\n" );
if (!lossy) {
/* make it readonly to avoid app changing data while we copy */
X11DRV_DIB_DoProtectDIBSection( physBitmap, PAGE_READONLY );
X11DRV_DIB_DoUpdateDIBSection( physBitmap, FALSE );
}
X11DRV_DIB_DoProtectDIBSection( physBitmap, PAGE_NOACCESS );
physBitmap->p_status = DIB_Status_AppMod;
physBitmap->status = DIB_Status_GdiMod;
break;
I tried to modify PAGE_NOACCESS and PAGE_READONLY to PAGE_READWRITE, AND the
screen got messed up, because the the order of the displaying bitmaps was
wrong, but the slowness problem disappeard completely! In this case, i am sure
its a LOCKING PROBLEM. Maybe the first X11DRV_BitBlt puts the region of the
window bitmap in PAGE_NOACCESS as we see above and the second X11DRV_BitBlt
has to wait for the first one to finish. I am not sure, i am still trying to
understand the difference between 'DIB_Status_AppMod' and 'DIB_Status_GdiMod'
since i found no documentation at all .. anyway, i am working on it! Help is
always welcome :)
--
Configure bugmail: http://bugs.winehq.org/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