FREETYPE的缓存.doc

,别把虾米不当海鲜。别把虾米不当海鲜。FreeType的缓存子系统提供了一个高性能的管理face、size、glyphimage和charmap的途径。:Whendealingwithfonts,esanecessityforatleastthefollowingreasons:当处理字体时,高速缓存是必要的,原因如下:l打开字体文件是相当慢的,因为它需要加载数据到内存中。所以,尽可能地保持FT_Face对象处于打开状态是一个好主意。l每一个FT_Face或FT_Size对象会占用几百KB,假设它总是很大,应该限制打开的face的个数到最小。l每个face包含成百上千的字形,由于通常只是使用一个face中的一小部分字形,一次性加载所有的字形是完全没有必要的。应该缓存我们经常使用的字形。l当属于给定face的所有字形已经载入内存时,对应的FT_Face对象可以被关闭已减少内存的占用。FreeType缓存子系统提供了自动完成上述任务的很好的途径。:FTC_Manager用于处理缓存中的各种数据。应首先调用FTC_Manager_New来创建它。:FTC_Manager并不直接知晓哪些字体被安装了或者在运行期是否有效。应用程序有责任定位和鉴别face,并打开相应的字体文件。这意味着应用程序必须使用一个指针(FTC_FaceID)来唯一鉴别一个给定的有效的或已安装的face。虽然这个指针对于FTC_Manager来说并不重要,但是它们的值在程序运行期必须始终保持不变,用于关联缓存的数据和它们相应的face。应用程序也必须提供(在FTC_Manager_New期间)一个专门的回调函数FTC_Face_Requester。这个外观请求器管理从一个给定的FTC_FaceID转换到一个新FT_Face对象,这通常暗示着调用FT_New_Face或FT_Open_Face。大多数情况下,FTC_FaceID指向一个包含着字体文件名和faceindex的结构。Inmostcases,aFTC_FaceIDisapointertoastructurethatcontainsafilepathnameandafaceindex,andwherethefacerequestersimplycallsFT_New_Face,asillustratedbythefollowingcode:/*definecustomfaceidentificationstructure*/typedefstructMyFaceRec_{constchar*file_path;intface_index;}MyFaceRec,*MyFace;/*ourcustomfacerequesterisdeadsimple*/staticFT_Errormy_face_requester(FTC_FaceIDface_id,FT_Librarylibrary,FT_Pointerrequest_data,FT_Face*aface){MyFaceface=(MyFace)face_id;//simpletypecasereturnFT_New_Face(library,face->file_path,face->face_index,aface);}{FTC_Managermanager;.../*initializecachemanager*/error=FTC_Manager_New(library,0,/*usedefault*/0,/*usedefault*/0,/*usedefault*/&my_face_requester,/*useourrequester*/NULL,/*don'tneedthis.*/&manager);}Whatthiscodedoesn'tshowishowthelistofavailable/existingFTC_FaceID/MyFacehandleisgenerated,,"ft2demos":客户程序不应当直接用FT_New_Face或FT_Open_Face来打开一个新的FT_Face对象,而是应该通过调用FTC_Lookup_Face接口来直接从cachemanag