[Bug 3902] Unnormal slowness in Heroes 4 (X11DRV_BitBlt?)

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=3902

------- Additional Comments From [e-mail]  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 :)