Re: [Freetype] LoadGlyph Time

[Vadim Plessky]

Hi David!

On Tuesday 30 April 2002 02:51, David Turner wrote:
|  Nir Rostoker a écrit :
|  >
|  > I have done some time measurements for  LoadChar()  function and was
|  > quite amazed to see its quite time consumption  function.
[...]
|  >
|  > Does anyone know if its normal ? Does anyone know a way to reduce it
|  > dramatically (enlarging the render pool might help) ?
|
|  There are three operations involved when loading a typical glyph bitmap:
|
|   A - outline "decompression: basically reading the file to
|       create a fill a FT_Outline with data points expressed
|       in font units
|
|   B - scaling the data points to device points and hinting
|       them to the pixel grid
|
|   C - converting the hinted outline to a monochrome bitmap
|       or anti-aliased pixmap.
|
|  Operation A is generally pretty fast, except for really complex
|  composites. On the other hand, B and C can be extremely time
|  consuming, depending on the glyph itself and the hinting and
|  rendering algorithms used..
|
|  Consider the following:
|
|    - hinting a TrueType glyph with native TT bytecode is
|      very long (you basically run a bytecode interpreter
|      where opcodes can perform complex 2d operations like
|      dot products and vector length measurements, all in
|      fixed-point arithmetic, so don't count on a FPU to
|      speed everything up)
|
|    - auto-hinting a glyph is also long. Because you first
|      need to analyze the whole glyph shape to find interesting
|      "features", then distort its data point to "optimize" them
|      to the pixel grid. The "feature detection" algorithm is
|      generally much longer than the "distorsion" one
|
|    - hinting a Type 1 glyph is probably a bit faster than
|      auto-hinting. However, it also uses some specific
|      "feature detection" phase since the information provided
|      by Type 1 hints is usually insufficient to produce very
|      high quality output

Well, if PS Type1 font has al hints "in place", than each glyph can be 
rendered pretty fast. AFAIK PS T1 model doesn't require complex 2D grid 
adjustment, etc. - in contrast with TT bytecode interpreter and its commands.

The only feature which PS Type1 hinting model doesn't have - rendering/hinting 
for diagonal stems.
There was discussion on this list concerning this problem (last year), and 
there was no common colclusion. May be, we should discuss it again?
I think we need to add some own "hints" to PS hinting model in order to 
overcome this limitations. Those hints can be used by FT2, and ignored by 
other PostScript interpreters - unless we will get Adobe to confirm to our 
extensions ;-)

So far, rendering of diagonal stems is unsatisfactory in FT 2.0.9.

Besides: are FamilyBlues and Other Blues values used by FreeType2/PS hinter?
I have impression that they are not.
Also I don't have explanation why Capital letters are displayd in Bold when 
normal letetrs dipslayd as Regular (say, at 12pt font size)
PostScript model effectively allows you to overcome such limitation of final 
rendering.
Or have I missed something?

|
|    - finally, scan-converting an outline can be costly when
|      its structure is complex. Typically, glyphs made of line
|      segments render much faster than those made of bezier
|      curves. That's why rendering the same text with Arial
|      will nearly always be faster than with Times New Roman
|      or Courier (independently of hinting overhead).
|
|  Note also that:
|
|    - the first time you try to load a glyph from a font
|      where the auto-hinter is used, the latter needs to
|      load and analyze several glyphs to compute global
|      metrics (i.e. blue values) that greatly increase
|      the output's quality. This can be _very_ long
|      compared to subsequent glyph load operations and
|      will definitely skew your average..

But, this doesn't happen when PS Type1 font is used, together with native 
hints?
Pls clarify.

|
|    - each time you change the pixel size of a TrueType
|      face (using the native bytecode interpreter), you
|      need to run a bytecode program whose task is to
|      re-compute all global metrics for the font. It's
|      not unusual to find more than 300 of these per
|      font, so this operation can be pretty long too
|      on each FT_Set_Pixel_Sizes (or FT_Set_Char_Size)
|
|  Try to toggle the FT_LOAD_NO_HINTING and FT_LOAD_RENDER
|  flags when calling FT_Load_Glyph. This will give you good
|  ideas regarding the "hot spots" that eat all of your
|  performance..
|
|  And finally, you should use a cache whenever you need
|  fast text rendering anyway.. unless you do things like
|  completely disable hinting (which generally helps a _lot_)
|

Really?
I remember you were referencing to Nautilus some time ago.
(as it doesn't use hints, only AA)
I have checked it carefully, and found that text rendered by Nautilus is very 
hard to read. Unless you use device with much better reolution than my 100dpi 
display.

|  Cheers,
|
|  - David Turner
|  - The FreeType Project (www.freetype.org)

Cheers,
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/