Topic: TTFs - WHY do they slow down a drawing?

[Guest]

I know True Type Fonts make a drawing slow, but the one thing I haven't been able to find much info is WHY they make a drawing slow.

Anyone....??

[Josh Nieman]

I always kind of wondered that too.

I assumed it had something to do with TTF not being a vector based file format (I think), and since Autocad is all about the vector math, a TTF*** would not compute as well.




***Bonus questions:  is a TTF something like image based, or what?  Is it actually raster or no?  If it's raster then how does it not lose quality when the letter is blown up or shrunk down in size, since when you increase or decrease a raster image, there is much distortion and loss of clarity/quality?

[deegeecees]

This may shed some light:

http://en.wikipedia.org/wiki/Computer_font#TrueType_Font

[Josh Nieman]

Well, aside from what is lost through a compiled file format... I get a TONNNNNNNNNN more jibberish when opening a TTF font in notepad, than if I opened a .shx font in notepad.

[Josh Nieman]

I don't see why, but apparently the difference lies in the linear definition of a vector based font format like .shx, which specifies basic line segments, whereas apparently (according to deegs link and the TRUE TYPE entry in wikipedia) a TTF uses quadratic formulas to specify curvature of fonts with extra "hinting language" to express further control over actual pixels at varying font sizes.

TTF also seems to be intended to be used at certain font sizes which I believe is point size, 9pt, 10pt, 36pt, etc... whereas in Autocad we force TTFs to conform to 3/32" or 1/8" or whatever we fancy.  This bastardization of size may contribute to some of the work the application must perform in order to properly render the TTF.

I still dunno, heh.  I think I am gonna go hit up Google a littler harder, though, because now I'm curious.

[Josh Nieman]

Not sure of the reliability of the source, but from: http://www.cadinfo.net/editorial/TTFacad.htm

In AutoCAD, the ‘Italic’ and ‘Bold’ attributes are offered but greyed-out when SHX fonts are used. However, the ‘slope’ and ‘width factor’ attributes that apply to SHX fonts are not greyed-out when TrueType is used, and I consider they should be. If you use TrueType and use any ‘slope’ or ‘width’ attributes, AutoCAD mimics the TrueType font characters using internally generated bitmaps. This is what then causes slow display and can also cause poor quality or ragged appearance. The slow-down can be quite extreme.

Of course that is if you modify width factors or slope.

If this remains true, then that is quite an inefficient rendering method that would cause these major problems in speed I hear about.  I don't use TTF except for exceptional cases like some clients title block logo or something, so I have not experienced the slow down.  I have also read, though, that the slow down has been vastly reduced (some claim it was eliminated, though doubtful) since Autocad 2000/2002 thereabouts.

Also worth note:

There are a couple of other circumstances that can upset AutoCAD’s implementation of TrueType and cause slow operation or poor appearance.

    * The text is part of a block insertion that has a scale factor other than 1, even if the x,y, and z scale factors are equal.
    * The text insertion point has a z value other than zero.

[Jeff_M]

FWIW, when TTF's were first allowed too be used in our DWG's we were warned about the slowdown. Trouble is, some people insisted on using them because they were "purdy". Opening these drawings took forever as did any regen and even redraws.

But that was many classes of processors ago.

Today, a good portion of my drawings utilize TTF's because they do still look good no matter what size they plot to. I rarely see a slowdown due to fonts any more.....instead, the slowdowns are now caused by Custom Objects in Civil3D and the reactors they use to stay in sync with each other.

[MickD]

Basically, TTF's are rendered polygon meshes if you like whereas std fonts are simple line work. To make a TTF character, the outside/inside boundaries are drawn and then it is triangulated to suit which involves many computations as you would imagine. As you may be aware, 'filling' concave polygons does not work so well so the character is broken down into triangles for rendering, another alternative is tessellation but this is also heavy on computation.
Different zooms/scales affect the computations also, this enable the font to be produced smoothly at any scale.
It's probably a lot more involved than that but that should help.

[Josh Nieman]

Basically, TTF's are rendered polygon meshes if you like whereas std fonts are simple line work. To make a TTF character, the outside/inside boundaries are drawn and then it is triangulated to suit which involves many computations as you would imagine. As you may be aware, 'filling' concave polygons does not work so well so the character is broken down into triangles for rendering, another alternative is tessellation but this is also heavy on computation.
Different zooms/scales affect the computations also, this enable the font to be produced smoothly at any scale.
It's probably a lot more involved than that but that should help.

This would be done by the video card or the processor?  In either case I would think the technology, though unable to avoid that tedious font rendering, would have advanced to speeds that would be able to handle heavy repetitious computations like that whether it be a workstation video card or a gaming video card, and if it is the processor, I think they've definitely made leaps and bounds enough to handle it.

With what you said in mind, I'm much more inclined to think that what Jeff M (and the others I came across in my search) is true... that the slow-down is now pretty much gone.

[sinc]

With what you said in mind, I'm much more inclined to think that what Jeff M (and the others I came across in my search) is true... that the slow-down is now pretty much gone.

I'm still a bit leery of them.  I've heard other people say that they work fine as long as all text is at Z=0, but there is a dramatic slowdown in drawings where lots of TTF entities are at elevations.  Don't know what version(s) of Autocad, or what hardware, and I haven't seen the slowdown myself, but I also haven't tried using TTFs enough.  I just don't trust them because of past history, I guess.

I definitely haven't been able to trust them enough to do something like create a bunch of Civil-3D styles that use them, then discover I'm seeing performance problems, and need to go back and fix all those styles again...  Working with C3D Styles is enough of a pain that I try not to mess with them more than I have to.

[MickD]

This would be done by the video card or the processor?

My guess would be that by their very nature TTF's are rendered by the processor, it would be quite an effort I think to 'code' the fonts to target any particular hardware for want of a better explanation.

While TTF's 'should' be faster to render these days, AutoCAD has never been an 'efficient' rendering engine, it doesn't need to be as it isn't rendering in 'realtime' like a game say. The reason is in its scene graph design, it is not optimised for 'real time' rendering like a game say where all the orange bullets get rendered in one pass, a cad engine is continually changing rendering states which slows down the processing a great deal.
AutoCAD does use hardware acceleration (if available) but it goes through it's own graphics interface first which is another bottleneck, it has to do this to ensure it works on various platforms.

For 2d work they seem ok, I've used them in 3d and had strange results so I canned them.

[Jeff_M]

I definitely haven't been able to trust them enough to do something like create a bunch of Civil-3D styles that use them, then discover I'm seeing performance problems, and need to go back and fix all those styles again...  Working with C3D Styles is enough of a pain that I try not to mess with them more than I have to.

With this I agree wholeheartedly. So far as I've gone, and probably as far as I'm going, is to use a TTF for the Lot Number in the Lot Label so it stands out.

MickD, thanks for the great explanation.

[Guest]

With what you said in mind, I'm much more inclined to think that what Jeff M (and the others I came across in my search) is true... that the slow-down is now pretty much gone.

You've obviously not had the chance to work with the ark-ee-tect that we've had the honor of working with - they LOVE their TTFs!!   

That, combined with MEP '08, is a recipe for slowing a PC to a grinding halt.

[Josh Nieman]

With what you said in mind, I'm much more inclined to think that what Jeff M (and the others I came across in my search) is true... that the slow-down is now pretty much gone.

You've obviously not had the chance to work with the ark-ee-tect that we've had the honor of working with - they LOVE their TTFs!!   

That, combined with MEP '08, is a recipe for slowing a PC to a grinding halt.

aaahhh ha... ok then... I think I'll stick with sinc's frame of mind... though we haven't had problems first hand, I'm still going to avoid them from fear and reputation

[pmvliet]

At a place of previous employment decided that Arial should be the standard font.
For a 42x30 sheet with nothing but arial font text at 3/32 or 1/8 was a nightmare!
This was the general note sheet and working in the file was not that bad, but it would
slow things down.

Plotting was a tremendous slow down and it created printer spooling files in the 100's MB
of size.

Yes it can make a drawing "pretty", but it does come at a cost....
Used appropriately, it can work well with Romans or others to make a clean, readable drawing.

Pieter