Re: [ft-devel] How to correctly use the cache ?

[David Turner]

On Sun, 08 Jul 2007 12:11:29 +0200, "Daniel Diaz" <address@hidden> said:
> Hi,
> 
> First of all thank you very much for this wonderful library.
> 
> I have searched the archive of this list, so I hope I don't ask neither
> a trivial question nor an already answered question.
> 
> I'd like to use the cache subsystem for font faces but some points are
> not clear enough. Here is what I have understood :
> 
> 1) I have to manage my own data structure (e.g. hash-table) to always
>     provide a unique FTC_FaceID  to the cache.
> 
this doesn't need to be as complex as a hash table. What's really required
is that every FTC_FaceID is unique and corresponds to an immutable font
reference. The demo program simply malloc a structure for each font listed
in a directory, and return their address as the FTC_FaceID.

> 2) The relation between a FCT_FaceID and a FT_Face is done by a callback
>     function (my face_requester function).
> 
> 3) It is up to me to  obtain a face (with FT_New_Face) and to maintain
>     the relation between a FCT_FaceID and a FT_Face.

the cache sub-system doesn't know anything about how fonts are installed and
accessed on your system. so basically, you abstract the font references through
a FTC_FaceID, and the cache uses them as follows:

- directly compares their value for lookups/matches
- calls the "face requester" callback to obtain a FT_Face object from it

the face requester must "translate" a FTC_FaceID into a new FT_Face object.
when the requester exists, the cache sub-system *owns* the FT_Face and will
be free to release it any time it deems appropriate.

> 4) I use FTC_Manager_LookupFace with a FTC_FaceID  to obtain a face from
>     the cache, which acts as follows:
>   4.1) if a FT_Face corresponding to FTC_FaceID is found it is
>        returned, else
>   4.2) if there is a free room the face is added to the cache, else
>   4.3) the oldest entry is removed from the cache and the new one is
>        added. The cache calls FT_Done_Face on the removed face.
> 
yes

> Q1) Is this correct ? BTW: it would be great if a "skeleton" of a user
> code could be added to the documentation.
> 

> Q2) There is an asymmetry: I create the face (FT_New_Face) but it is
> destroyed by the cache (4.3). I conclude my face_requester function is
> ONLY called in 4.3 and thus has to perform a FT_New_Face /
> FT_New_Memory_Face. Is it ok ?

yes, the idea is that *you* know how to access the font files (where they're
stored, either on disk/memory/wathever), so you should be responsible for
creating the FT_Face. After that, the cache sub-system manages the object(s)

 I ask this because initially I tough I could keep triplets <path_name, 
font_index, FT_Face> in my data
> structure (and thus the face_requester simply returns the associated
> FT_Face).  BTW: this also could be documented.
> 

you don't need to keep the FT_Face, a FTC_FaceID would typically point to a
(path, face_index) tuple, but can also be more complex depending on your needs.
the important point is that the content referenced by the FTC_FaceID should not
change between cache API calls.

> Q3) Is there a way to be informed when an entry is removed from the
> cache (4.3) ?
>
no, and you shouldn't know, this would only make things more complex,
and probably slower too.
 
> Q4) Else, how can I remove useless entries from my own data structure ?
> I mean if the cache only uses max_faces entries, I'd like to use tmore
> or less he same amount for my own data structure (it is for an embedded
> application where memory usage is crucial) ? From what I have understood
> my data structure always grows... If true this is a serious
> (un)limitation :-)
> 
you don't need to manage the FT_Face objects yourself, they're are totally
owner by the cache sub-system once the face requester exits. Of course, you
can still open other FT_Face objects in other parts of your code, but they
will simply not be used/managed by the cache itself...

Hope this helps,

- David Turner

> Thank you very much for your help.
> 
> 
> 
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel