Graham Asher wrote:
Some caveats about my glyph caching system: here is most of the text of
my reply to Srinavasa:
lt;lt;lt;lt;lt;lt;
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.
gt;gt;gt;gt;gt;gt;
Best regards,
Graham Asher
Hi Graham,
Could you please point from where in the mentioned link i can get a your
caching code which you have developed for the symbian.
http://developer.symbian.org/oss/FCL/sf/os/textandloc/file/030b3432fbe0/fontservices/fontstore
Regards,
Gaurav
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
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
--
View this message in context:
http://old.nabble.com/Scope-for-parallelization-in-freetype-library-tp27846183p28545895.html
Sent from the Freetype - Dev mailing list archive at Nabble.com.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
