[ft-devel] my Symbian OS glyph caching system

[Graham Asher]

Some caveats about my glyph caching system: here is most of the text of my reply to Srinavasa:

<<<<<<
You are welcome to look at my cache implementation: it should be somewhere in this folder:

http://developer.symbian.org/oss/FCL/sf/os/textandloc/file/030b3432fbe0/fontservices/fontstore

However:

1. I can't provide support. I wrote this over 10 years ago. Since then many other people have worked on it and I no longer know exactly how it works.

2. As originally designed, the glyph cache was a binary tree that grew to a certain maximum size, after which no more entries could be added. For reasons of performance in a multi-processing system, glyphs could only be added, not deleted, addition of a glyph to a tree being an atomic action requiring no mutex. This design restriction may not exist any more; I don't know and don't have the time to find out.

3. Therefore you may be better advised, in a single-processing system, to create your own LRU glyph caching system. In principle it's simple (and I have used a variant of this design for my proprietary CartoType map rendering library): create a suitable database structure that stores key-value pairs where the key is the unique style of the glyph (font family, size, transform, emboldening, etc.) and the value is the glyph. Keep track of the least recently used glyph using a linked list; or simply rely on hashing, and remove glyphs where a conflict occurs.
>>>>>>

Best regards,

Graham Asher



Werner LEMBERG wrote:

We are trying to achieve performance improvement either through
parallelization/optimization in the freetype-2.3.11 library.  Any
help in this regard is highly appreciated.
    

The solution is caching everything!  Due to the nature of fonts I
don't see much gain in parallelization while processing a single font.

Graham Asher mentioned in a previous post that his FreeType caching
stuff from the symbian OS is now open-source, so you might use this as
a starting point.

  http://lists.gnu.org/archive/html/freetype-devel/2010-02/msg00033.html

If you can optimize FreeType further (for example, using a profiler to
isolate hot spots, then rewriting the code to make it faster) this is
very welcomed.


    Werner


_______________________________________________
Freetype-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/freetype-devel