http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #34 from Jan Ploski jpljpl@gmx.de 2008-09-20 18:55:23 --- (In reply to comment #33)
Well, another test... and with DIB_Coerce disabled no font displayed. I guess Autocad uses 2 different font rendering paths, depending maybe on the complexity of displayed drawing. Quite difficult to find, also because Autocad don't run with relay/snoop enabled.
Maybe WINEDEBUG=+bitmap,+font can give you additional clues.
I also found myself hacking together an extra debug routine to output timestamped backtraces on demand (using backtrace_symbols_fd).
I can confirm that some other paths for drawing text exist. In the TSE2 game there was one piece of text which kept appearing no matter what I disabled.
In X11DRV_DIB_Coerce the calls to X11DRV_DIB_DoUpdateDIBSection seem to be the most relevant/time consuming. They eventually cause X11DRV_DIB_GetImageBits and X11DRV_DIB_SetImageBits to be invoked via X11DRV_DIB_DoCopyDIBSection.
For the record, here is my understanding of the overall concept of dib.c. This may be helpful for further debugging: This module serves to keep in sync the contents of "physical bitmaps" (possibly located in video memory) and the "device-independent bitmaps" (DIBs, in main memory). Application code may attempt to access a DIB at times when the physical bitmap has been updated by some calls to GDI code and is newer than the DIB content in the main memory (apparently not every write goes through the DIB). In this case, before the application can perform the actual memory read or write, the physical bitmap's content must be copied back to the DIB. The mechanism used to detect this event is memory page protection - the DIB memory is kept write-protected or even access-protected when the physical bitmap is "dirty", so that when the application tries to write/read the DIB, it causes a segmentation fault (or whatever it's called under Windows). This fault is trapped and handled by the routine X11DRV_DIB_FaultHandler. It updates the DIB memory to ensure up-to-dateness, releases the protection, and returns the control back to the application thread. At other times, the DIB is newer than the physical bitmap and has to be copied into the other direction. The X11DRV_DIB_Coerce routine is the central coordination point which takes care of the copying, page protection, and updating the bitmap structure's status to reflect the current degree of synchronization between a DIB and its corresponding physical bitmap.