freetype-devel
[Top][All Lists]
Advanced

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

[ft-devel] RE: my Symbian OS glyph caching system


From: Srinivas Katti
Subject: [ft-devel] RE: my Symbian OS glyph caching system
Date: Thu, 11 Mar 2010 16:41:58 +0530

Thank for the information sir , it was very informative.

 


From: Graham Asher [mailto:address@hidden
Sent: Thursday, March 11, 2010 4:23 PM
To: Werner LEMBERG
Cc: address@hidden; address@hidden
Subject: my Symbian OS glyph caching system

 

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
 
  

 


reply via email to

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