Re: [ft] First pretest of FreeType 2.1.10

2005-06-01 Thread Werner LEMBERG
So the good news is that with the 2.1.9-style sigma, FT 2.1.10pre is much better than FT 2.1.9 for FT_Glyph_Stroke(), and no worse than FT 2.1.9 for FT_Glyph_StrokeBorder(). David wrote me that his sigma change tried to fix a peculiar case -- he no longer has the original data, unfortunately.

[ft-cvs] freetype2 ./ChangeLog src/base/ftstroke.c

2005-06-01 Thread Werner LEMBERG
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Werner LEMBERG [EMAIL PROTECTED] 05/06/01 15:30:44 Modified files: . : ChangeLog src/base : ftstroke.c Log message: * src/base/ftstroke.c

[ft-devel] does the face cache really work ?

2005-06-01 Thread Anstinus Anstinus
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 **

RE: [ft-devel] does the face cache really work ?

2005-06-01 Thread Turner, David
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 contained

RE: [ft-devel] does the face cache really work ?

2005-06-01 Thread Anstinus Anstinus
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