FF8 and DirectMusic

[Martin Lexa]

* Johan Gill (johane at lysator.liu.se) wrote:

> This is probably related to something more graphical.
  Probably yes. Here is my current investigation:

  Debug:
  ------

  wine --debugmsg +module,+x11drv,+ddraw,+win32,+gdi FF8Config.exe

  [...]
  trace:ddraw:User_DirectDrawSurface_final_release waiting for update
  thread to terminate...
  trace:ddraw:User_DirectDrawSurface_final_release update thread
  terminated
  trace:ddraw:DIB_DirectDrawSurface_free_dc Releasing DC for surface:
  0x403df0a0

  [Point 1] X11DRV_SelectBitmap called
  trace:gdi:GDI_GetObjPtr (0044): enter 1
  trace:gdi:SelectObject hdc=00c8 0044
  trace:gdi:GDI_GetObjPtr (00c8): enter 2
  trace:gdi:GetStockObject returning   44
  trace:gdi:GDI_GetObjPtr (0044): enter 3
  trace:gdi:GetStockObject returning   44
  trace:x11drv:X11DRV_SelectBitmap Before wine_tsx11_lock()
  err:ntdll:RtlpWaitForCriticalSection section 0x40cd0644
  "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec)
  tid=080720a8
  [End of point 1]

  Code:
  -----

  HBITMAP X11DRV_SelectBitmap( X11DRV_PDEVICE *physDev, HBITMAP
	hbitmap )

	[...]

    /* Change GC depth if needed */
	   
	if (dc->bitsPerPixel != bmp->bitmap.bmBitsPixel)
	{
		TRACE("Before wine_tsx11_lock()\n");
		wine_tsx11_lock();
		TRACE("After wine_tsx11_lock()\n");
		XFreeGC( gdi_display, physDev->gc );
		physDev->gc = XCreateGC(gdi_display, physDev->drawable,	0, NULL );
		XSetGraphicsExposures(gdi_display,physDev->gc,False );
		XSetSubwindowMode(gdi_display,physDev->gc,IncludeInferiors);
		XFlush(gdi_display);
		TRACE("Before wine_tsx11_unlock()\n");
		wine_tsx11_unlock();
		TRACE("After wine_tsx11_unlock()\n");
	}
	
	GDI_ReleaseObj(hbitmap);
	return hbitmap;

  static void nop(void)
  {
  }
	 
  void (*wine_tsx11_lock)(void) = nop;
  void (*wine_tsx11_unlock)(void) = nop;

  Why there is no locking mechanism? This should be the problem, shouldn't be?

  If running wine with --debugmsg +all FF8Config:

  [...]
  [Point 1] X11DRV_SelectBitmap called
  080720a8:Call x11drv.SelectBitmap(403ff140,00000044) ret=407a7268
  080720a8:trace:win32:_EnterSysLevel (0x407de7a4, level 3): thread
  0x80720a8 (fs 008f, pid 4757) count before 2
  080720a8:trace:win32:_EnterSysLevel (0x407de7a4, level 3): thread
  0x80720a8 (fs 008f, pid 4757) count after  3
  080720a8:trace:gdi:GDI_GetObjPtr (0044): enter 3
  080720a8:trace:gdi:GetStockObject returning   44
  080720a8:trace:gdi:GDI_ReleaseObj (0044): leave 3
  080720a8:trace:win32:_LeaveSysLevel (0x407de7a4, level 3): thread
  0x80720a8 (fs 008f, pid 4757) count before 3
  080720a8:trace:win32:_LeaveSysLevel (0x407de7a4, level 3): thread
  0x80720a8 (fs 008f, pid 4757) count after  2
  080720a8:Ret  x11drv.SelectBitmap() retval=00000044 ret=407a7268
  [End of point 1]
  [...]
  
  As you can see function SelectBitmap run without any problems and
FF8Config works correctly.

  Which "debug message slowing" is so important? These
in win32:_EnterSysLevel and win32:_LeaveSysLevel. If I disable any TRACEs,
messages, etc. in these two functions then running wine
'with --debugmsg +all' FF8Config will hang.

  This should be some kind of race condition bug. Or am I wrong? Could
someone help me with this? I don't know wine internals too much but I'd
like to solve this. Thank you.

Martin