RE: [Freetype] the joys of FT_Set_Char_Size()

[Turner David]

Hello Carten,

> To share a FT_Face object between multiple instances of that 
> font face at
> differing sizes...
> 
> [ prose removed ]
> 
> So yes. I suspected FT_Set_Char_Size() would be a little 
> nasty so I already wrapped it so it would only call it *IF*
> the font face that was shared was REALLY being used at a
> new size... even with this in, the performance hit was
> shocking! But now instead I have to load the font face 
> multiple times instead if I use the same font at more than one size.
> 

Yes, FT_Set_Char_Size is costly, and this is why you can have several FT_Size
objects for a given FT_Face. See the documentation here:

  http://www.freetype.org/freetype2/docs/reference/ft2-sizes_management.html

The idea is that FT_Activate_Size is *much* faster than FT_Set_Char_Size
(since it only changes a few pointers). On the other hand, you'll now have to
deal with several FT_Size objects per FT_Face in your cache.

I also strongly suggest to use the FreeType Cache sub-system. That's
because:

 - I'm pretty certain that it will be at least as fast as your cache, if not 
faster
   (I have heavily tuned this code, and it's performing very well even for
  relatively atrocious usage patterns)

 - it manages FT_Face and FT_Size objects automatically for you. It can
   also limit the number of FT_Face and FT_Size opened at the same time.
   this is great to bound memory usage.

the cache is still in beta but is rapidly approaching its stable release. I
recommend using the latest version of the API documentation (found on
the website), or even better the documentation comments found within
the source files (i.e. <freetype/ftcache.h> and <freetype/cache/*.h>

<freetype/ftcache.h> contains everything you need to use the
existing cache sub-system. <freetype/cache/*.h> contains
information that is only relevant if you want to add a new cache
type, if you need to.

by the way, you can also use the cache to perform character code => glyph
index mapping, since using the CMap cache is usually twice faster than
calling FT_Get_Char_Index directly.

> [prose removed]
>
> Is my only choice to turn off kerning? Is there something int
> the freetype api that lets me get some form of kerning
> rule table per glyph (ie left if glyph = X, kerning modifiers 
> are for right
> glyph: Y = -2, Z = 1, A = 3, B = 5, G = 2, J = -2)... ?
>
There is nothing like this for the moment, though I'd like to add it myself.
I'd also prefer the ability to have an kerning table iterator that dumps
all (left,right) pairs available in the table.  this is easier to implement
and gives more freedom when implementing a cache on top.

For the moment, you have the options of:

- use the FreeType cache to activate the size you need (i.e. 
FTC_Manager_LookupSize)
  and FT_Get_Kerning to get the kerning value. That's what I do for the moment,
  and it's not too bad, even though it's far from optimal

- write a custom cache that records the FT_Get_Kerning results for a given
  glyph prefix (for example, other schemes are possible).

I believe that I'll write the kerning cache as soon as the iterator works 
correctly.
However, don't hold your breath, I have more important things to do for the
moment, as most other developers of the FreeType Project...

Regards,

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

-- 
> ------------- Codito, ergo sum - "I code, therefore I am" 
--------------
> The Rasterman (Carsten Haitzler)    address@hidden
> 熊耳 - 車君 (数田)                  address@hidden
> Tokyo, Japan (東京 日本)
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/freetype
> 

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
NDS TECHNOLOGIES FRANCE will not therefore be liable for the message if 
modified.