| ftcache.c |
END |
771 |
| ftcbasic.c |
Basic Families
|
16761 |
| ftccache.c |
this one _must_ be a power of 2! |
13683 |
| ftccache.h |
handle to cache object |
15587 |
| ftccback.h |
FTCCBACK_H_ |
2031 |
| ftccmap.c |
Each FTC_CMapNode contains a simple array to map a range of character
codes to equivalent glyph indices.
For now, the implementation is very basic: Each node maps a range of
128 consecutive character codes to their corresponding glyph indices.
We could do more complex things, but I don't think it is really very
useful.
|
9723 |
| ftcerror.h |
This file is used to define the caching sub-system error enumeration
constants.
|
999 |
| ftcglyph.c |
create a new chunk node, setting its cache index and ref count |
4979 |
| ftcglyph.h |
FTC_GCache is an _abstract_ cache object optimized to store glyph
data. It works as follows:
- It manages FTC_GNode objects. Each one of them can hold one or more
glyph `items'. Item types are not specified in the FTC_GCache but
in classes that extend it.
- Glyph attributes, like face ID, character size, render mode, etc.,
can be grouped into abstract `glyph families'. This avoids storing
the attributes within the FTC_GCache, since it is likely that many
FTC_GNodes will belong to the same family in typical uses.
- Each FTC_GNode is thus an FTC_Node with two additional fields:
* gindex: A glyph index, or the first index in a glyph range.
* family: A pointer to a glyph `family'.
- Family types are not fully specific in the FTC_Family type, but
by classes that extend it.
Note that both FTC_ImageCache and FTC_SBitCache extend FTC_GCache.
They share an FTC_Family sub-class called FTC_BasicFamily which is
used to store the following data: face ID, pixel/point sizes, load
flags. For more details see the file `src/cache/ftcbasic.c'.
Client applications can extend FTC_GNode with their own FTC_GNode
and FTC_Family sub-classes to implement more complex caches (e.g.,
handling automatic synthesis, like obliquing & emboldening, colored
glyphs, etc.).
See also the FTC_ICache & FTC_SCache classes in `ftcimage.h' and
`ftcsbits.h', which both extend FTC_GCache with additional
optimizations.
A typical FTC_GCache implementation must provide at least the
following:
- FTC_GNode sub-class, e.g. MyNode, with relevant methods:
my_node_new (must call FTC_GNode_Init)
my_node_free (must call FTC_GNode_Done)
my_node_compare (must call ftc_gnode_compare)
my_node_remove_faceid (must call ftc_gnode_unselect in case
of match)
- FTC_Family sub-class, e.g. MyFamily, with relevant methods:
my_family_compare
my_family_init
my_family_done
- FTC_GQuery sub-class, e.g. MyQuery, to hold cache-specific query
data.
- Constant structures for a FTC_GNodeClass.
- MyCacheNew() can be implemented easily as a call to the convenience
function FTC_GCache_New.
- MyCacheLookup with a call to FTC_GCache_Lookup. This function will
automatically:
- Search for the corresponding family in the cache, or create
a new one if necessary. Put it in FTC_GQUERY(myquery).family
- Call FTC_Cache_Lookup.
If it returns NULL, you should create a new node, then call
ftc_cache_add as usual.
|
11080 |
| ftcimage.c |
finalize a given glyph image node |
3584 |
| ftcimage.h |
FTC_ICache is an _abstract_ cache used to store a single FT_Glyph
image per cache node.
FTC_ICache extends FTC_GCache. For an implementation example,
see FTC_ImageCache in `src/cache/ftbasic.c'.
|
2675 |
| ftcmanag.c |
FTC_MruNode_CompareFunc node_compare |
16615 |
| ftcmanag.h |
A cache manager is in charge of the following:
- Maintain a mapping between generic FTC_FaceIDs and live FT_Face
objects. The mapping itself is performed through a user-provided
callback. However, the manager maintains a small cache of FT_Face
and FT_Size objects in order to speed up things considerably.
- Manage one or more cache objects. Each cache is in charge of
holding a varying number of `cache nodes'. Each cache node
represents a minimal amount of individually accessible cached
data. For example, a cache node can be an FT_Glyph image
containing a vector outline, or some glyph metrics, or anything
else.
Each cache node has a certain size in bytes that is added to the
total amount of `cache memory' within the manager.
All cache nodes are located in a global LRU list, where the oldest
node is at the tail of the list.
Each node belongs to a single cache, and includes a reference
count to avoid destroying it (due to caching).
|
5734 |
| ftcmru.c |
zero new node in case of node_init failure |
6615 |
| ftcmru.h |
An MRU is a list that cannot hold more than a certain number of
elements (`max_elements'). All elements in the list are sorted in
least-recently-used order, i.e., the `oldest' element is at the tail
of the list.
When doing a lookup (either through `Lookup()' or `Lookup_Node()'),
the list is searched for an element with the corresponding key. If
it is found, the element is moved to the head of the list and is
returned.
If no corresponding element is found, the lookup routine will try to
obtain a new element with the relevant key. If the list is already
full, the oldest element from the list is discarded and replaced by a
new one; a new element is added to the list otherwise.
Note that it is possible to pre-allocate the element list nodes.
This is handy if `max_elements' is sufficiently small, as it saves
allocations/releases during the lookup process.
|
8322 |
| ftcsbits.c |
/
/************************************************************************ |
11911 |
| ftcsbits.h |
/
FT_END_HEADER
#endif /* FTCSBITS_H_ |
2191 |
| rules.mk |
|
2308 |