RE: [ft] Internal cache questions

[Turner, David]

Hello,

>     Hi!
>     I'm really new to FreeType and would like to
> receive some feedback from you experienced users :)
> I've read the FreeType docs regarding the internal
> cache system, but I'm not good enough to understand it
> and adapt it to my current source. Could you, please,
> take a look at my code at
> http://majin.i-blog.net/majinft.zip (uses C++ and
> OpenGL) and answer me:
> 
>     1) It is worth worrying about this internal cache
> system? Is there critical speed or memory consumption
> improvements?
>

I only had a very quick look at your code, but it seems
that you're simply implementing a "glyph container" rather
than a cache. I.e. you store one full FT_Face per font
object, and keep all loaded glyph bitmaps in memory until
the object is discarded.

In other words, your code is probably fast, but certainly
uses a lot of memory when using many fonts at the same
time.

The FreeType cache subsystem was designed for the following
reasons:

  1/ To limit the number of FT_Face and FT_Size objects
     that are opened concurrently. That's because each
     such objects are relatively heavy (a FT_ Face can be
     > 30 Kb, depending on the font file, and library
     configuration options, FT_Size objects are generally
     tiny, except if you use the bytecode interpreter, since
     they must include the whole virtual machine state and
     stack, which can add a lot.)
 

  2/ To limit the amount of memory used to store the
     glyph bitmaps (or outlines) themselves. For example,
     you can specify that the cache should not use more
     than 100 Kb to store the bitmaps. When the cache is
     full, bitmaps are ejected from the cache on a LRU
     basis, which seems sufficient for text rendering.


  3/ To allow fast bitmap loading in the general case
     (i.e. displaying text with several different fonts,
     but using only a fraction of a given font file's
     glyphs).

The code has also been designed to be relatively flexible,
though it's not the simplest thing on earth, mainly because
I didn't want to sacrifice too much performance in the name
of developer convenience.

This also means that it's possible to write a faster and 
simpler cache for your own project if you want to.

It's up to you to decide wether it's worth using it or not
for your own uses.


>     2) What is the right thing to do, since the manual
> says "Client applications should not open new FT_Face
> objects directly with FT_New_Face"? Could you
> exemplify directly into the code?
> 

The cache subsystem is a completely optional component.
You don't need to use it, and you can use it in parallel
with wathever code you want.

The comment simply means that you shouldn't use FT_New_Face
to create FT_Face objects that will be managed by the
cache manager. That's all.

You're still free to create your own FT_Face objects, but
you'll have full responsability regarding their lifecycle
management. They can be used in parallel with the cache
subsystem though.


Hope this helps,

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


>     Thanks a lot!!!
> 
> PS.: As you can see from the source, I'm already using
> an external font cache based on {font name, font
> size}, but that doesn't help me when I need to build
> dozens of different sized fonts with the same font
> name. On the other side, cached FT_Size's won't make a
> difference;
> 
> PS.: My code is based on Sven Olsen's tutorial at NeHe
> (http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=43);
> 
> PS.: If you like it, feel free to use at your ouwn
> risk :) and tell me if you had found a bug;
> 
> 
>       
>       
>               
> ____________________________________________________
> Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! 
> http://mail.yahoo.com.br
> 
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype
>