[Bug 13801] Very slow text rendering in AutoCAD

[wine-bugs at winehq.org]

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





--- Comment #34 from Jan Ploski <jpljpl at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.