Re: [Freetype] LoadGlyph Time

[David Turner]

Hi Nir,


Nir Rostoker a écrit :
> 
> Hi,
> 
> I have done some time measurements for  LoadChar()  function and was quite
> amazed to see its quite time consumption  function.
> 
> I have done the measurements both on Font files that I have loaded to ROM
> and both for files I have loaded to Flash, on both cases none of the data id
> used from a file, so I have expected the operations in LoadChar() to be
> short ones , since reading the relevant data (unloaded tables like for
> instance the glyphlocation and tables that were stored in the ROM by
> OpenFace() ) should not be long.
> 
> The measurements showed me that on average LoadChar() takes around 20
> Millisecond !
> 
> 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

  - 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..

  - 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_)


Cheers,

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