freetype-devel
[Top][All Lists]
Advanced

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

Re: Caching rotated glyphs?


From: David Turner
Subject: Re: Caching rotated glyphs?
Date: Mon, 30 Oct 2000 15:30:45 +0100

Hi Karsten,

> 
> Hi David,
> 
> I just hacked around a bit with the caching system using some bits from
> ftcommon.i and ftview.c (from ft2demos).
> Looking up non-rotated glyphs seems to work, but when I apply transformation
> on the requested face I keep getting an error code of -1 from
> FTC_Image_Cache_Lookup.
> Is the cache system capable of caching rotated glyph images? Did I do
> something wrong?
> I didn't have time to debug the caching code yet, so any pointers are
> appreciated.
> 

The Cache sub-system is very flexible and extensible, which means that you
should be able to cache any kind of glyph image in theory. However, you'll
probably need some work to do it. I'll try to explain it briefly:

  - first of all, you should never set the transform in the FT_Face objects
    that your face requester returns to the cache manager. Doing this would
    have serious unexpected consequences.

  - the "cache manager" object is in charge of three things:

      o first, if provides a small cache of FT_Face and FT_Size objects.
        these are created through a mapping between abstract FT_FaceID
        keys and real FT_Face objects by a user-provided callback named
        the "face requester". The latter should simply deal with mapping
        face ids to normal FT_Face object, and nothing else.


      o second, it manages a LRU list of "cache nodes", while ensuring that
        the total of all nodes do not excess a fixed amount of memory
        determined at manager creation time.

        the cache manager doesn't create the cache nodes itselft, it can only
       "size" them, and remove/destroy them from the cache. The manager doesn't
        even know what a cache node is.


      o third, it manages a list of "cache objects". Each cache handles its
        own kind of cache nodes, and adds them to the manager's list when
        appropriate. Each cache must be "registered" in the manager before use.


      o the current cache sub-system comes by default with two cache classes, 
but
        we'll focus on FTC_Image_Cache only. This cache object simply stores
        FT_Glyph objects in cache nodes. It is used as follows:

          - first, a new cache object is created and registered in the manager
            by calling FTC_Image_Cache_New

          - then, individual glyph images are seached through 
FTC_Image_Cache_Lookup
            this function returns a FT_Glyph handle (or NULL in case of 
failure),
            and works as follows:

               - if the glyph if found in the cache's list of nodes, it is
                 returned immediately

               - otherwise, a new cache node is created and added to the
                 manager's list of nodes. A new FT_Glyph object is loaded
                 into it.

               - finally, the manager is checked to see wether the cache memory
                 limit was reached. If this is the case, then "old" cache nodes
                 are flushed out of the cache, as many as necessary to stay 
below
                 the limit.


      o FTC_Image_Cache is a sub-class of the abstract FTC_Glyph_Class defined
        in <freetype/cache/ftcglyph.h>. The latter is only in charge of 
implementing
        a basic object cache that uses cache nodes to store glyphs (alternate
        schemes are possible, see <freetype/cache/ftcchunk.h>).

        what FTC_Image_Cache adds, it the ability to store a FT_Glyph in a
        "glyph node", as well as selection of the proper image format
        for the gory details, see the function "ftc_glyph_image_node_new"
        in "src/cache/ftcimage.c".

        basically, FTC_Image_Cache is the place where support for transformed
        glyphs should be added. It currently doesn't support it though.


      o You can create you own cache object class to support transforms if you
        need them. I'd suggest starting from the FTC_Image_Cache code and
        modify it slightly to create a new FTC_MyImage_Cache.

      o Another solution would be to directly modify FTC_Image_Cache to support
        transforms. I'm ready to add it if enough people are interested in this,
        but first, so let me know..

  However, note that I don't think that caching rotated images is a good idea.
  I'd rather suggest to store unscaled glyph outlines in the cache, and
  transform/rotate them when you need to. Unless you need to display _lots_ of
  rotated text, of course :-)

Best Regards,

- David                                   

PS: OK, I'm not finsihed with this :-)

    note that a single cache node takes at least 20 bytes (due to overhead 
needed
    to list it correctly both in the manager and the cache objects).

    In some cases, like when caching small monochrome glyph bitmaps, that might
    represent a _lot_ of memory per cache node, and using FTC_Image_Cache is a
    real waste of resources.

    So, the cache sub-system comes with another abstract cache class, called
    a FTC_Chunk_Class. Its purpose is to be able to store several glyphs in a
    single cache node, in order to divide the overhead significantly.

    for example, the FTC_SBit_Class cache object is a sub-class of 
FTC_Chunk_Class
    that is used to store "small bitmaps" in chunks of 16 glyphs per cache node.
    each bitmap is stored in a small and compact FTC_SBitRec structure,
    resulting in obvious savings of memory..

    You could also imagine sub-classing FTC_Chunk_Class for other purposes, like
    caching small glyph metrics (without the images) to perform layout with 
them,
    or even language coverage information, etc.. :-)

> Thanks,
> Karsten



reply via email to

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