http://bugs.winehq.org/show_bug.cgi?id=13801
Summary: Very slow text rendering in AutoCAD Product: Wine Version: 1.0-rc4 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: max@veneto.com
Tested on AutoCAD 2005 and AutoCAD 2008, after installation following http://bugs.winehq.org/show_bug.cgi?id=13799 guidelines.
Working on a drawing with many texts/quotes zooms/scrolls/pans becomes painfully slow. Bug concerns just texts, NOT images or other drawing elements. I suppose is a performance problem on gdi, but not sure about.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #1 from max@veneto.com 2008-06-09 10:52:38 --- Created an attachment (id=13840) --> (http://bugs.winehq.org/attachment.cgi?id=13840) Sample to reproduce slow text render
Here a sample drawing to show the problem. It doesn't appear at first. First try panning the image a bit (mid mouse button). If it pans smoothly, then try to zoom in and out (mouse wheel). At a moment on zooming the program seems to hang. That's the right zoom position to reproduce the bug, or a step inner/outer from it.
The strange stuff is that the bugf appears only at a certain zoom factor, if bigger or smalle it doesn't. It seems to me that autocad changes output data (or function) depending on text zoom factor.
I really don't know which trace/relay should I output to locate the bug.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #2 from max@veneto.com 2008-06-17 03:52:01 --- (In reply to comment #1)
Created an attachment (id=13840)
--> (http://bugs.winehq.org/attachment.cgi?id=13840) [details]
Sample to reproduce slow text render
Here a sample drawing to show the problem. It doesn't appear at first. First try panning the image a bit (mid mouse button). If it pans smoothly, then try to zoom in and out (mouse wheel). At a moment on zooming the program seems to hang. That's the right zoom position to reproduce the bug, or a step inner/outer from it.
The strange stuff is that the bugf appears only at a certain zoom factor, if bigger or smalle it doesn't. It seems to me that autocad changes output data (or function) depending on text zoom factor.
I really don't know which trace/relay should I output to locate the bug.
Ciao
Max
As an update to that one, I noticed that the problem is in truetype fonts filling. Disabling font filling in Autocad (must choose 3d wireframe mode) the speed is good enough.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
max@veneto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal Platform|PC-x86-64 |All Version|1.0-rc4 |1.0.0
--- Comment #3 from max@veneto.com 2008-06-20 17:51:32 --- Bug depends only on ExtTextOutW() function. There should be a way to speed it up....
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |PC-x86-64 Version|1.0.0 |1.0-rc4
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-20 22:44:24 --- (In reply to comment #3)
Bug depends only on ExtTextOutW() function.
How have you found that ExtTextOutW is the culprit?
(Please don't change an originally reported version).
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #5 from max@veneto.com 2008-06-21 04:22:16 --- (In reply to comment #4)
(In reply to comment #3)
Bug depends only on ExtTextOutW() function.
How have you found that ExtTextOutW is the culprit?
First, a trace on font, gdi and so; then, when found the place where text is output (just a single line text in autocad, then panning the screen), I made 2 tests... one with 3d wireframe mode, on which just the outline of font is displayed on autocad, and which shows NO ExtTextOutW calls, another one with 2d wireframe on which fonts are painted well and filled, on which the call IS used. I don't attach logs because I guess they're unuseful, but if you like I can do it.
In conclusion : panning/zooming in 2d wireframe mode IS slow and IS using ExtTextOutw(); panning/zooming in 3d wireframe mode IS FAST and doesn't use ExtTextOutW. I think (but not sure about...) that 3d wireframe does buffering on line segments composing the font and draws it directly on dc. It's far less accurate, and you can see the coarse painting of font.
BTW, on far zooms I think autocad optimizes out fonts, just drawing some small box instead of them; that's because my test drawing (see attached file...) behaves fast on very near zooms (few fonts to paint) and on very far zooms (fonts optimized out).
(Please don't change an originally reported version).
Why not ? I upgraded wine to git, and the behaviour is unchanged. It make sense, IMHO, to tell it...
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #6 from max@veneto.com 2008-06-21 04:47:35 --- BTW, ExtTextOutW is the culprit for this bug, but there's another slow down, seen on particular zoom factors. It doesn't make use of ExtTextOutW but makes panning even slower (5-6 seconds for a pan...) on my test drawing. Fonts are "paint" as strange blocks... I must still investigate if autocad uses a third way to "optimize" them for this scale factor. I'm thinking that it makes some bitmaps and puts them on screen with some sort of bitblt operation, but thato one should be another bug report, I guess.
I don't know if it makes sense to attatch a test drawing, as these bugs depends on zoom factor, so on user screen resolution, sizes of autocad window on screen and so on. My test drawing is composed of a matrix of 33x17 single line texts, size 30, spaced normally (about 1/2 size vertically, 1 size orizontally) containing string "PIPPO", in Bookman Old Style font; anyways any true type font does the job.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #7 from max@veneto.com 2008-06-21 05:01:55 --- Patching this code (from Line 1946 of Font.c), commenting out the pExtTextOut() ; [code] if (PATH_IsPathOpen(dc->path)) ret = PATH_ExtTextOut(dc, x, y, (flags & ~ETO_OPAQUE), &rc, glyphs ? glyphs : reordered_str, count, deltas); else // ret = dc->funcs->pExtTextOut(dc->physDev, x, y, (flags & ~ETO_OPAQUE), &rc, // glyphs ? glyphs : reordered_str, count, deltas); ret = TRUE; }
done: [/code] Makes panning as fast as in 3d mode (obviously no text is displayed!). Anyways it doesn't interfere (nor solve) the other bug I pointed to in my previous post.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #8 from max@veneto.com 2008-06-21 05:40:36 --- Created an attachment (id=14234) --> (http://bugs.winehq.org/attachment.cgi?id=14234) gdi+font trace on second bug
Now a gdi+font trace on second kid of bug, the one that makes panning really slow (5-10 seconds for a pan with ~650 texts on page). It appears only in 2d mode (the most used) and for particular zoom factors. On this zoom factor texts are unreadable (quite small filled rectangles); on trace output there are NO outputs of real text, but a bunch of repeated (thousands of) chunks of gdi calls. I've tried to isolate the repeating sequence and attached right here.
I'm afraid that's the last test I can do without proper hints... My skills on wine gdi handling ends here :-) I hope somebody will look at it.. I can do any log and/or tests, but I must know what to do :-) That bug makes about unusable autocad on 2d wireframe mode, which is the most useful, as it shows linetypes and objects completely.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #9 from max@veneto.com 2008-06-21 05:54:46 --- Last comment... all that happens JUST with fonts. I tried with many repeated very complex objects (hatchs for example) but speed is ok, similar to AutoCAD on XP. Even an array of 17x33 of rectangles filled with a wooden hatch (which is very complicated one) is usable, about no slower than on XP. Problem appears (up to now...) just on text objects.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000@yahoo.co.uk
--- Comment #10 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-06-21 06:25:47 --- Hi max, maybe i'm doing something wrong, but i cannot reproduce the slow-downs with the attached *.dwg file. any hint?
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #11 from max@veneto.com 2008-06-21 06:45:27 --- (In reply to comment #10)
Hi max, maybe i'm doing something wrong, but i cannot reproduce the slow-downs with the attached *.dwg file. any hint?
I guess that's my fault, I usually use a non-standard true type font... Bookman. You can change the font of texts using any truetype font; if you don't do and you don't have bookman, autocad substitutes all with built-in ugly txt font (or similar) which is not truetype.
After changing, look at text, you can easily see it it's truetype. When you've it ok, just try small zooms in-out with mouse wheel. At a certain step, autocad will appear hang for 2-3 seconds. If you go too far, the bug disappears, as Autocad uses a different rendering approach. When you get the right zoom factor, try panning.... it hangs depending on screen content from 1-2 seconds up to 6-10 seconds.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #12 from max@veneto.com 2008-06-21 06:51:06 --- BTW, test file is just to show where's the problem.... If you open any "real" drawing with some quotes and texts, using truetypes, and with viewmode in 2d wireframe (99% of people use this one), you'll notice the slowness. Changing to 3d wireframe the problem disappears.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #13 from max@veneto.com 2008-06-23 04:42:30 --- Could you reproduce it ? It's a really annoying stuff working on real dwgs...
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #14 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-06-26 04:42:38 ---
Could you reproduce it ?
No, i don't know how to ensure that autocad uses the truetype fonts. I copied over all my truetype fonts to windows/Fonts, and played a bit with the attached *dwg file, but i son't see slow downs. Could you give a bit more info how to get the true type fonts used in the *.dwg? thx
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #15 from max@veneto.com 2008-06-26 04:56:23 --- (In reply to comment #14)
Could you reproduce it ?
No, i don't know how to ensure that autocad uses the truetype fonts. I copied over all my truetype fonts to windows/Fonts, and played a bit with the attached *dwg file, but i son't see slow downs. Could you give a bit more info how to get the true type fonts used in the *.dwg? thx
Just use STYLE command, and change typeface of currently selected style (bookman in my example file). It was my fault, I posted an example with a seldom font I use but not standard to windows. With STYLE command, select a TrueType font as tipeface (you'll see them because they've got a Tt before name in drop-down listbox. As the example is quite small, you'll notice the slowdown only on a praticular zoom factor. First try to pan the drawing; if it's smooth, slowly zoom with the wheel, in and/or out, one step each time. As the problem arises on a zoom factor that depends on monitor size and other stuffs, I can't be sure that it'll appear at first. You'll notice the right zoom factor when, zooming a bit more (in or out) you'll notice a long delay (1-2 seconds) before image gets updated. Once you find it, try to pan; if it goes smooth, you've zoomed too far, so try to go back (in or out depending on previous zoom). You'll find a zoom factor on which panning becomes a pain. This is a VERY small sample; on real drawings it becomes really unusable. If you still can't reproduce it, I can send to you a real drawing on which there's no "good" zoom factor, it's slow everytime.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #16 from max@veneto.com 2008-06-26 04:57:37 --- ah, just another stuff.... it depends really ONLY on TT fonts; I'm working right now on a very complicated 3d stuff and it goes very fast, but no fonts in.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #17 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-06-27 07:47:05 ---
This is a VERY small sample; on real drawings it becomes really unusable. If you still can't reproduce it, I can send to you a real drawing on which there's no "good" zoom factor, it's slow everytime.
I still don't see the slow down... Could you attach the "real" drawing, with which the bug is very clear ti see, to this bug? thx
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #18 from max@veneto.com 2008-06-27 09:08:24 --- Created an attachment (id=14392) --> (http://bugs.winehq.org/attachment.cgi?id=14392) First "real" test file, TTF fonts, view in 2d wireframe mode
So, here the first test drawing. View is set on 2d wireframe mode. Try pan the drawing with mid mouse button, you'll see that's unusable. Set the view mode to 3d wireframe; you'll see that fonts are just "approximated", they've the outline, some of them is paint in wrong scale (that one should be another bug.....) but the panning becomes usable. Next attachment, all fonts replaced with txt one (no TT, but builtin vector font).
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #19 from max@veneto.com 2008-06-27 09:10:57 --- Created an attachment (id=14393) --> (http://bugs.winehq.org/attachment.cgi?id=14393) Second "real" test file, all TTF fonts replaced with built-in vector font
Here the second one, same as first, but all fonts replaced with non-ttf ones. You can see panning it, it's very fast, even better than autocad on win xp. Viewmode is set to 2d, so the slowest one. Setting to 3d wireframe doesn't change.
http://bugs.winehq.org/show_bug.cgi?id=13801
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #20 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-06-27 11:11:46 --- Hi, i can see slow downs now yeah; it still seems workable but maybe that's because i have a very expensive fast computer ;)
Unfortunatley it's impossible to get a +relay log, probably copyprotection? So currently rather stuck now. The only thing i noticed is that when i compilw wine with the ./configure --without-freetype option the slowness seems to be gone again, but then again the fonts look rather ugly. Is that the same for you
I wonder if other programs like eDrawingsViewer behave the same. Could you give that a try http://www.edrawingsviewer.com/
i see a bit of a difference in speed, can you confirm that. Maybe we could get a +relay from that app, pionting to the cause for autocad
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #21 from max@veneto.com 2008-06-27 11:23:33 --- (In reply to comment #20)
Hi, i can see slow downs now yeah; it still seems workable but maybe that's because i have a very expensive fast computer ;)
Wow, finally confirmed !!! :-) I've got a quite fast notebook (core 2 duo, 2.4 GHz), but for me that's NOT workable.... Well, I'm very fast using cad, indeed :-) BTW, that one was a "purged down" drawing, still not the real one.... That one I'm finishing it, it'll become 3 times as complex on the end... And if you start working on paper space the slow down is multiplied by 5 at least.
Unfortunatley it's impossible to get a +relay log, probably copyprotection? So currently rather stuck now. The only thing i noticed is that when i compilw wine with the ./configure --without-freetype option the slowness seems to be gone again, but then again the fonts look rather ugly. Is that the same for you
Well, I guess that taking out freetype makes wine to not use TT, so it's the same case ad second example I've post. I tried too a relay/snoop, but no way.... those damn'd copy protections... their only usefulness is to make problems to registered users. Even a trace+all don't work, but yesterday I could manage to have some traces on gdi,graphics, x11, fonts, bitmap, and so on. It seems to me that on TT fonts it makes hard usage of bitmap2dib and dib2bitmap copy... but I'm not very good on analyzing it. You can do yourself, use the pipe trick in wiki, it does speed up very much the analysis clipping down the trace output.
I wonder if other programs like eDrawingsViewer behave the same. Could you give that a try http://www.edrawingsviewer.com/
i see a bit of a difference in speed, can you confirm that. Maybe we could get a +relay from that app, pionting to the cause for autocad
I'll try it this night... Is it an autodesk app ? I think the problem is because of some sort of optimization autodesk put inside autocad, used just on particular zoom factors. Maybe some older autocad has the same behaviour and less dummy copy protection scheme ?
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #22 from max@veneto.com 2008-06-27 13:44:15 --- Tested on eDrawingViewer, it works fast on both drawings.... So, no slow down at all. True type fonts in eDrawingm when zoomed very close, are ugly facetted, so maybe it uses a different rastering algorhythm than autocad. We could also test Intellicad (i.e. Bricscad V8), but that one is much slower than autocad on redrawing screen.... and I guess it uses different rendering tools. Maybe autodesk has a free downloadable viewer ?
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #23 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-06-27 14:10:34 ---
Maybe autodesk has a free downloadable viewer ?
hmm, i guess that would be this one?: http://bugs.winehq.org/show_bug.cgi?id=12532
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #24 from max@veneto.com 2008-06-27 14:27:15 --- (In reply to comment #23)
Maybe autodesk has a free downloadable viewer ?
hmm, i guess that would be this one?: http://bugs.winehq.org/show_bug.cgi?id=12532
Yep, but that one fails to install... I guess it's like autocad 2009, needing dotnet 3.0. I'll look for a previous version somewhere... but it's becoming dumb to follow useless software upgrades.....
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #25 from max@veneto.com 2008-07-15 16:27:30 --- Well, I guess the bottleneck is in X11DRV_LockDIBSection() and X11DRV_UnlockDIBSection().... Maybe some threading problem ? Disabling both functions speeds up stuffs of a factor of 50-100.... Of course with some quirks on font display.
If somebody with enough skills on that could give a look at that one it would be great...
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #26 from max@veneto.com 2008-07-21 07:39:34 --- Can somebody please give me an hint on what to look for in order to resolve this bug ?? That's becoming really annoying.... The speed difference with and without TT fonts on drawing is about 1:100 .... from totally unusable to faster than on xp...
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #27 from Damjan Jovanovic damjan.jov@gmail.com 2008-07-22 00:34:00 --- Do you get any warnings or fixmes when running Autocad in a console and the drawing gets slow?
Does it run faster if the X server is in 16 bit color?
http://bugs.winehq.org/show_bug.cgi?id=13801
Jan Ploski jpljpl@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpljpl@gmx.de
--- Comment #28 from Jan Ploski jpljpl@gmx.de 2008-09-14 07:54:47 --- (In reply to comment #25)
Well, I guess the bottleneck is in X11DRV_LockDIBSection() and X11DRV_UnlockDIBSection().... Maybe some threading problem ? Disabling both functions speeds up stuffs of a factor of 50-100.... Of course with some quirks on font display.
I found a new way to reproduce this bug - not with AutoCAD, but with a free demo version of the game "The Spirit Engine 2". It can be obtained here: http://www.thespiritengine.com/tse2-download.html
This game is a nice test case because it is unbearably slow from the very start - when it fades in a credits screen with some (Arial) text on it and the fade is noticeably slow. The slowdown becomes much even more apparent during fight scenes in the game when a lot of text is rendered.
Commenting out the calls to X11DRV_LockDIBSection and X11DRV_UnlockDIBSection in X11DRV_XRender_ExtTextOut fixes the slowdowns, but it also makes all text disappear completely, so it is not an acceptable workaround.
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #29 from Jan Ploski jpljpl@gmx.de 2008-09-14 10:38:50 --- (In reply to comment #28)
(In reply to comment #25)
Well, I guess the bottleneck is in X11DRV_LockDIBSection() and X11DRV_UnlockDIBSection().... Maybe some threading problem ? Disabling both functions speeds up stuffs of a factor of 50-100.... Of course with some quirks on font display.
I found a new way to reproduce this bug - not with AutoCAD, but with a free demo version of the game "The Spirit Engine 2". It can be obtained here: http://www.thespiritengine.com/tse2-download.html
This game is a nice test case because it is unbearably slow from the very start
- when it fades in a credits screen with some (Arial) text on it and the fade
is noticeably slow. The slowdown becomes much even more apparent during fight scenes in the game when a lot of text is rendered.
Commenting out the calls to X11DRV_LockDIBSection and X11DRV_UnlockDIBSection in X11DRV_XRender_ExtTextOut fixes the slowdowns, but it also makes all text disappear completely, so it is not an acceptable workaround.
(The description below refers to wine-1.1.4 source:)
I narrowed it down even more. Making X11DRV_DIB_Coerce to become a no-op has the same beneficial effect for performance (with the same side effect of text not being displayed at all).
The same effect wrt performance can be also achieved by commenting out the invocation of VirtualProtect in X11DRV_DIB_DoProtectDIBSection. However, this causes a great distortion in the displayed content (not just vanishing text).
Overall, it seems to me like some sort of lock contention problem, with NtProtectVirtualMemory being called a lot of times from the execution path containing DrawTextExA, X11DRV_XRender_ExtTextOut, X11DRV_LockDIBSection, X11DRV_DIB_Coerce.
Fixing this will require more insight into the DIB code than I have. I imagine that some cheaper alternative to the currently employed NtProtectVirtualMemory mechanism might exist.
http://bugs.winehq.org/show_bug.cgi?id=13801
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #30 from Jan Ploski jpljpl@gmx.de 2008-09-20 09:27:16 --- (In reply to comment #29)
Overall, it seems to me like some sort of lock contention problem, with NtProtectVirtualMemory being called a lot of times from the execution path containing DrawTextExA, X11DRV_XRender_ExtTextOut, X11DRV_LockDIBSection, X11DRV_DIB_Coerce.
I have to retract that. Further experiments reveal that the locking mechanism per se does not cause trouble. The bad performance can be instead attributed to the call to XShmGetImage in X11DRV_DIB_GetImageBits (which is invoked a lot from X11DRV_DIB_Coerce when text rendering operations are performed). Commenting out just that call makes, like the previously described actions, all text disappear and restores good performance.
Elsewhere I read that XShmGetImage may be slow because of pixel data being stored directly in the video memory and having to be transferred to the main memory. Inspired by this explanation, I switched from the proprietary nvidia driver 96.43.07 (my video card is a GeForce4 MX 440 AGP) to the framebuffer device driver. Lo and behold, it also restored good performance! This workaround is easy and good enough for playing the TSE2 game, but probably too drastic in general. However, it could also be that the particular versions of the nvidia driver and video hardware are to blame, so it is recommended that other people try to reproduce this bug to help estimate its significance.
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #31 from max@veneto.com 2008-09-20 13:19:39 --- (In reply to comment #30)
I have to retract that. Further experiments reveal that the locking mechanism per se does not cause trouble. The bad performance can be instead attributed to the call to XShmGetImage in X11DRV_DIB_GetImageBits (which is invoked a lot from X11DRV_DIB_Coerce when text rendering operations are performed). Commenting out just that call makes, like the previously described actions, all text disappear and restores good performance.
Elsewhere I read that XShmGetImage may be slow because of pixel data being stored directly in the video memory and having to be transferred to the main memory. Inspired by this explanation, I switched from the proprietary nvidia driver 96.43.07 (my video card is a GeForce4 MX 440 AGP) to the framebuffer device driver. Lo and behold, it also restored good performance! This workaround is easy and good enough for playing the TSE2 game, but probably too drastic in general. However, it could also be that the particular versions of the nvidia driver and video hardware are to blame, so it is recommended that other people try to reproduce this bug to help estimate its significance.
I tried to remove the XShmGetImage() call from inside dlls/winex11.drv/dib.c but it did nothing to AutoCAD.... uhmm... need some more testing.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #32 from max@veneto.com 2008-09-20 13:29:40 --- (In reply to comment #31)
(In reply to comment #30)
I have to retract that. Further experiments reveal that the locking mechanism per se does not cause trouble. The bad performance can be instead attributed to the call to XShmGetImage in X11DRV_DIB_GetImageBits (which is invoked a lot from X11DRV_DIB_Coerce when text rendering operations are performed). Commenting out just that call makes, like the previously described actions, all text disappear and restores good performance.
Elsewhere I read that XShmGetImage may be slow because of pixel data being stored directly in the video memory and having to be transferred to the main memory. Inspired by this explanation, I switched from the proprietary nvidia driver 96.43.07 (my video card is a GeForce4 MX 440 AGP) to the framebuffer device driver. Lo and behold, it also restored good performance! This workaround is easy and good enough for playing the TSE2 game, but probably too drastic in general. However, it could also be that the particular versions of the nvidia driver and video hardware are to blame, so it is recommended that other people try to reproduce this bug to help estimate its significance.
I tried to remove the XShmGetImage() call from inside dlls/winex11.drv/dib.c but it did nothing to AutoCAD.... uhmm... need some more testing.
Max
But, indeed, disablng X11DRV_DIB_Coerce() does speed stuffs enormously.... And, strange enough, the fonts ARE displayed correctly. But, many glitches in graphics bitmap are present.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #33 from max@veneto.com 2008-09-20 13:36:03 --- 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.
Max
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.
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #35 from max@veneto.com 2008-09-21 04:38:26 --- Well, digging a bit more I discovered that, for Autocad, the function used to output texts inside drawings (not the menu and toolbars ones...) is
PATH_ExtTextOut() in dlls/gdi32/path.c
Making this one a no-op speeds up Autocad but without TT fonts inside drawing. BTW, I found another bug about autocad TT fonts... it's a display problem that I noted before. Fonts are displayed erratically depending on their position on screen, it seems like they're rotated out of the viewing plane. I'll try to investigate a bit more on that function. Can you please try if your app speeds also up disabling this call ?
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #36 from Jan Ploski jpljpl@gmx.de 2008-09-21 05:09:25 --- (In reply to comment #35)
Well, digging a bit more I discovered that, for Autocad, the function used to output texts inside drawings (not the menu and toolbars ones...) is
PATH_ExtTextOut() in dlls/gdi32/path.c
Making this one a no-op speeds up Autocad but without TT fonts inside drawing. BTW, I found another bug about autocad TT fonts... it's a display problem that I noted before. Fonts are displayed erratically depending on their position on screen, it seems like they're rotated out of the viewing plane. I'll try to investigate a bit more on that function. Can you please try if your app speeds also up disabling this call ?
I just tried and this has no effect in the TSE2 game. The piece of text which was being displayed after I had disabled the other functions still keeps appearing, and the game is still slow.
So now we know that there are at least 3 different text drawing paths :)
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #37 from max@veneto.com 2008-09-21 06:00:38 --- (In reply to comment #36)
I just tried and this has no effect in the TSE2 game. The piece of text which was being displayed after I had disabled the other functions still keeps appearing, and the game is still slow.
So now we know that there are at least 3 different text drawing paths :)
Yep... and I guess that'll make more difficult to locate the problem. I'll try to look inside PATH_ExtTextOut() to see where it goes... maybe it'll join you path somewhere.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #38 from max@veneto.com 2008-09-21 06:08:36 --- Well, some more info. The 'count' parameter (whathever its purpose is....) changes depending on text position on window... which seems to me wrong, but I'm not sure. With my example text, with text near left windows border the count is 5, going to right of window (panning cad drawing) count goes down up to 1 and at same time the text width shrinks, which IS wrong, indeed. So, there's obviously some bug BEFORE PATH_ExtTextOut() call. BTW, in PATH_ExtTextOut() there's a loop executed 'count' times that calls PATH_add_outline(); making the latter no-op speeds up drawing again, of course with no TT text displayed.
So, besides the 'slow text bug' there's at least another bug that changes text width depending on its position inside window... I'll investigate a bit more before opening a new bug report. It would be good to have a short testcase, but I'm not able to write it.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #39 from max@veneto.com 2008-09-21 06:32:37 --- Another finding.... The text I was looking into had a very small (1e-9) z coordinate, which made it to go through PATH_ExtTextOut() routine, with the problem above (shrinking of text depending on screen position). That's another bug, probably texts with non null Z coordinate are handled differently by autocad. So, back to previous problem, with normal text. I'll file another bug report for the problem above on next days.
So, by now I'll look again for codepath used for drawing normal texts on autocad window.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #40 from max@veneto.com 2008-09-21 08:09:14 --- I tried to get further, but no way... there are too many paths used by autocad to render fonts, depending on too many factors, as text zooming, and so on. IMHO to solve this problem would be needed some deep changes on dib/gdi routines, which are far beyond my wine skills. The only stuff I'm still sure is that dropping TT fonts from autocad drawings speeds up enormously the stuff, as normal vector fonts are rendered from inside autocad itself skipping wine fonts routines. Maybe the (future ?) implementation of a DIB engine will solve the problem.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |421
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #41 from max@veneto.com 2009-01-24 16:46:46 --- Using the test DIB engine (patch in bug 421 page) autocad 2005 becomes usable with TT fonts too. Still some display bugs, but I'm working on it.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Danila Sentiabov dsent.zen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13801
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com
--- Comment #42 from Roderick Colenbrander thunderbird2k@gmail.com 2009-07-08 04:28:59 --- Hi,
I'm working on replacing big chunks of the Wine bitblt code with XRender. This will in the end also eliminate some DIB bottlenecks because XRender can do depth conversion, so we don't have to that during a X11DRV_DIB_SetImageBits and in other places.
It was mentioned in this bug report that text rendering is slow due to a part of the DIB stuff. Did you perform any profiling e.g. using sysprof/oprofile to see which functions consume most time? In the report depth conversion isn't mentioned but I guess that this might be one of the most time consuming parts. Is this the case? My work might be able to accelerate AutoCad quite a bit (sure not as much as a complete DIB engine).
Roderick
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #43 from max@veneto.com 2009-07-08 04:36:37 --- (In reply to comment #42)
Hi,
I'm working on replacing big chunks of the Wine bitblt code with XRender. This will in the end also eliminate some DIB bottlenecks because XRender can do depth conversion, so we don't have to that during a X11DRV_DIB_SetImageBits and in other places.
It was mentioned in this bug report that text rendering is slow due to a part of the DIB stuff. Did you perform any profiling e.g. using sysprof/oprofile to see which functions consume most time? In the report depth conversion isn't mentioned but I guess that this might be one of the most time consuming parts. Is this the case? My work might be able to accelerate AutoCad quite a bit (sure not as much as a complete DIB engine).
Roderick
I didn't make a true profiling, but some (long) time ago I traced down the code flow, and the bottleneck was (IIRC....) on ExtTextOut function, which did some DIB_Coerce() calls. Removing the coerce stuffs gave back the speed at the expense of missing text, obviously. The problem is not the bitblt, but the text output on a dib with format different than screen's one. I guess your patch won't speed up this stuff..... Of course, if you have a way to use XRENDER to paint fonts on different bit depths without doing a conversion, then yes, you can have the speed gain. But then you should patch ExtTextOut() functions to use yours.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #44 from Roderick Colenbrander thunderbird2k@gmail.com 2009-07-08 04:51:43 --- (In reply to comment #43)
(In reply to comment #42)
Hi,
I'm working on replacing big chunks of the Wine bitblt code with XRender. This will in the end also eliminate some DIB bottlenecks because XRender can do depth conversion, so we don't have to that during a X11DRV_DIB_SetImageBits and in other places.
It was mentioned in this bug report that text rendering is slow due to a part of the DIB stuff. Did you perform any profiling e.g. using sysprof/oprofile to see which functions consume most time? In the report depth conversion isn't mentioned but I guess that this might be one of the most time consuming parts. Is this the case? My work might be able to accelerate AutoCad quite a bit (sure not as much as a complete DIB engine).
Roderick
I didn't make a true profiling, but some (long) time ago I traced down the code flow, and the bottleneck was (IIRC....) on ExtTextOut function, which did some DIB_Coerce() calls. Removing the coerce stuffs gave back the speed at the expense of missing text, obviously. The problem is not the bitblt, but the text output on a dib with format different than screen's one. I guess your patch won't speed up this stuff..... Of course, if you have a way to use XRENDER to paint fonts on different bit depths without doing a conversion, then yes, you can have the speed gain. But then you should patch ExtTextOut() functions to use yours.
Ciao
Max
The patch will in the end eliminate any depth conversion (at least on the Wine side a driver might still do it internally but it can use more optimizations and in the best case does it all in hardware). When the patch is done we can directly blit DIBs with a depth different from the screen depth to the screen. What depths are used for the DIBs?
Roderick
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #45 from max@veneto.com 2009-07-08 05:40:03 --- (In reply to comment #44)
The patch will in the end eliminate any depth conversion (at least on the Wine side a driver might still do it internally but it can use more optimizations and in the best case does it all in hardware). When the patch is done we can directly blit DIBs with a depth different from the screen depth to the screen. What depths are used for the DIBs?
Roderick
Don't remember, but the point isn't blitting of dibs to screen (which can be indeed a big advantage if done by hardware....) but the DRAWING on DIBs which are of different depth than screen.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Luke Benstead kazade@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kazade@gmail.com
--- Comment #46 from Luke Benstead kazade@gmail.com 2009-07-21 08:13:34 --- I just installed the Autocad 2008 trial to test the speed of font rendering when font-smoothing is both enabled and disabled (recently Thunderbird and I noticed that font rendering can be 70x faster if font smoothing is enabled).
However, I've been totally unable to find any slow down at all. Everything is quite snappy with both smoothing enabled and disabled and using the attached samples.
Max, can you retest this in 1.1.26 without the DIB engine? I'm wondering if Thunderbird's recent XRender updates have had a knock on effect. It might just be that my PC is too fast to notice though :)
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #47 from max@veneto.com 2010-09-12 10:09:02 CDT --- (In reply to comment #46)
I just installed the Autocad 2008 trial to test the speed of font rendering when font-smoothing is both enabled and disabled (recently Thunderbird and I noticed that font rendering can be 70x faster if font smoothing is enabled).
However, I've been totally unable to find any slow down at all. Everything is quite snappy with both smoothing enabled and disabled and using the attached samples.
Max, can you retest this in 1.1.26 without the DIB engine? I'm wondering if Thunderbird's recent XRender updates have had a knock on effect. It might just be that my PC is too fast to notice though :)
Hi Luke,
I tested it recently on a production drawing, and the slowness is still there. If you don't notice it, check if :
1) You've got enough text on display, and test it on various zoom scales 2) You've got TT fonts on display. The default (txt) font used by autocad is a self-drawn vector font which doesn't suffer of the problem. Even if you open a drawing which contains TT fonts, if they're not installed on your system they'll be replaced by txt and so are fast.
So, if you want to test it correctly, do the following :
1) Install msttcorefonts (for example with winetricks) 2) create a new drawing, set up a style using, for example, arial font 3) Draw some hundreds of texts with it. You can do multiple copies of the same text.
You'll notice the difference from vector fonts (txt, simplex, romans, romand) and TT fonts (arial, ....) as latter appears filled, former just outlined (and looks ugly....). You'll see that with enough text displayed panning the drawing becomes completely useless, you'll need some seconds (!!!) to pan the drawing. With the engine enabled, it's instantaneous.
Ciao
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
Bug 13801 depends on bug 421, which changed state.
Bug 421 Summary: Implement a DIB engine http://bugs.winehq.org/show_bug.cgi?id=421
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
http://bugs.winehq.org/show_bug.cgi?id=13801
--- Comment #48 from max@veneto.com 2011-12-03 10:14:35 CST --- Still an issue, even with latest addition of text output in current DIB engine. I have no idea if dib text routines are too slow or if there's still something missing, but AutoCad2005 with many text on drawing is still unusable.
Max
http://bugs.winehq.org/show_bug.cgi?id=13801
max@veneto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #49 from max@veneto.com 2012-01-15 13:28:00 CST --- Fixed in 1.3.37
http://bugs.winehq.org/show_bug.cgi?id=13801
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #50 from Alexandre Julliard julliard@winehq.org 2012-01-27 14:17:15 CST --- Closing bugs fixed in 1.4-rc1.
-
wine-bugs＠winehq.org