[Bug 13801] New: Very slow text rendering in AutoCAD
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(a)winehq.org ReportedBy: max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #1 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #2 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 max(a)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(a)veneto.com 2008-06-20 17:51:32 --- Bug depends only on ExtTextOutW() function. There should be a way to speed it up.... Max -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|All |PC-x86-64 Version|1.0.0 |1.0-rc4 --- Comment #4 from Dmitry Timoshkov <dmitry(a)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). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #5 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #6 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #7 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #8 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #9 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000(a)yahoo.co.uk --- Comment #10 from Louis Lenders <xerox_xerox2000(a)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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #11 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #12 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #13 from max(a)veneto.com 2008-06-23 04:42:30 --- Could you reproduce it ? It's a really annoying stuff working on real dwgs... Max -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #14 from Louis Lenders <xerox_xerox2000(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #15 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #16 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #17 from Louis Lenders <xerox_xerox2000(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #18 from max(a)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). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #19 from max(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #20 from Louis Lenders <xerox_xerox2000(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #21 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #22 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #23 from Louis Lenders <xerox_xerox2000(a)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
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #24 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #25 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #26 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov(a)gmail.com --- Comment #27 from Damjan Jovanovic <damjan.jov(a)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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Jan Ploski <jpljpl(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpljpl(a)gmx.de --- Comment #28 from Jan Ploski <jpljpl(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #29 from Jan Ploski <jpljpl(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #30 from Jan Ploski <jpljpl(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #31 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #32 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #33 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #34 from Jan Ploski <jpljpl(a)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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #35 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #36 from Jan Ploski <jpljpl(a)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 :) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #37 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #38 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #39 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #40 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |421 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #41 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Danila Sentiabov <dsent.zen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsent.zen(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Roderick Colenbrander <thunderbird2k(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k(a)gmail.com --- Comment #42 from Roderick Colenbrander <thunderbird2k(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #43 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #44 from Roderick Colenbrander <thunderbird2k(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #45 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Luke Benstead <kazade(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kazade(a)gmail.com --- Comment #46 from Luke Benstead <kazade(a)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 :) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #47 from max(a)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 -- 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.
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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 --- Comment #48 from max(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 max(a)veneto.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #49 from max(a)veneto.com 2012-01-15 13:28:00 CST --- Fixed in 1.3.37 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=13801 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #50 from Alexandre Julliard <julliard(a)winehq.org> 2012-01-27 14:17:15 CST --- Closing bugs fixed in 1.4-rc1. -- 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.
participants (1)
-
wine-bugs＠winehq.org