freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Devel] Cache sub-system re-visited


From: Turner David
Subject: [Devel] Cache sub-system re-visited
Date: Wed, 24 Dec 2003 11:23:06 +0100

Hello,

  I recently commited a complete rewrite of the cache sub-system
  to the FreeType CVS. This work was mandated by the following
  limitations:

    - there was no support for de-installation of faces. More
      precisely, a FTC_FaceID was considered persistent by the
      cache engine, which could cause problems when the content
      of a FTC_FaceID changed (typically when uninstalling a
      font, and installing a new one)

      there is no an API named "FTC_Manager_RemoveFaceID" which
      will delete all "idle" nodes that correspond to a given
      FTC_FaceID. all "locked" nodes (i.e. those with a reference
      count > 0), will be modified to prevent them from appearing
      in further lookups (they will be cleaned normally when
      their reference count reaches 0).

      this should completely solve the problem


   - there was no support for point scaling (i.e. providing
     character sizes in points + dpis, instead of pixels).


   - lack of abstraction in the image & sbit cache. These components
     could not be easily re-used to implement application-specific
     caches.

       there are now 3 abstract cache classes:

         FTC_GCache : used to store one glyph item per cache node,
                      with the ability to group common attributes
                      into "families"  (replaced the old FTC_GlyphCache)

         FTC_ICache : used to store one FT_Glyph per cache node. extends
                      FTC_GCache. Family definition/comparison and glyph
                      loading are however left to sub-classes

         FTC_SCache : used to store up to 16 small bitmaps per cache node.
                      extends FTC_GCache. Family definition/comparison and
                      glyph loading are however left to sub-classes

     Meanwhile, the file "src/cache/ftcbasic.c" implements:

         FTC_ImageCache : extends FTC_ICache, implements family definitions
                          and glyph loading similar to the old API

         FTC_SBitCache  : extends FTC_SCache, implements family definitions
                          and glyph loading similar to the old API

     Client applications should be able to extend FTC_GCache, FTC_ICache
     or FTC_SCache much more easily (i.e. less code to write, and less
     callbacks). For example, one could envision caches that are capable
     of storing transformed (obliqued), stroked, emboldened or colored
     glyph images. Use "ftcbasic.c" as an example.


  IMPORTANT NOTICE:

   - the API was slightly modified, and isn't completely stable yet. This
     should happen in January. The changes won't be drastic though.

   - all public APIs are now in "include/freetype/ftcache.h", a.k.a. FT_CACHE_H
     the content of "include/freetype/cache/" is only needed by applications
     that wish to implement their own caches.

   - there were some major performance improvements through the use of various
     tricks. Cache hits are up to 70% faster than in the old code.

   - the FTC_CMapCache has been simplied. charmaps can only be accessed by index
     right now. There is also an API named FT_Charmap_GetIndex for this
     purpose.

   - the demo programs have been updated to the new code. The previous versions
     will not work with the current one.


Comments welcome,

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

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
NDS TECHNOLOGIES FRANCE will not therefore be liable for the message if 
modified.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]