[Top][All Lists]
[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