Anstinus Anstinus wrote:
Consider the situation: I looked up a FT_Face by myFaceID1 at first,
then at a later time, I want to get the same FT_Face. Should I find
the myFaceID1 in my list and use it to lookup a FT_Face , or create a
new myFaceID2 with the same content as myFaceID1 ?
You shou
On Thu, Jun 02, 2005 at 02:52:58AM +, Anstinus Anstinus wrote:
> Consider the situation: I looked up a FT_Face by myFaceID1 at first, then
> at a later time, I want to get the same FT_Face. Should I find the
> myFaceID1 in my list and use it to lookup a FT_Face , or create a new
> myFaceID2
> An important design point of the cache subsystem is that a
> FTC_FaceID value (i.e. the address contained by the pointer) is used
> to _uniquely_ identify a given cacheable face.
>
> This is essential to perform fast lookups (a pointer comparison is
> so much faster than calling a callback that
Thanks for the answer.
more question here:
You don't need to cache your My_FaceID_Rec objects. Just build a list
of them, corresponding to the list of available faces you have, and
that's all. The lifecycle of FT_Face objects is handled automatically
by the cache sub-system.
Consider the situa
Hello Anstinus,
> But the face_id is just a pointer, then if I write the
> following code, it
> will not work as I expect:
>
> [code removed]
>
> The ftFace1 and ftFace2 will have the same value!
>
An important design point of the cache subsystem is that a
FTC_FaceID value (i.e. the address co
I find that the function ftc_face_node_compare() use " return FT_BOOL(
node->face_id == face_id );" to determine whether a node exists in the MRU
list.
But the face_id is just a pointer, then if I write the following code, it
will not work as I expect:
* code begin *
