freetype
[Top][All Lists]
Advanced

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

[ft] freetype and multithread


From: Erich Martin
Subject: [ft] freetype and multithread
Date: Mon, 13 Feb 2006 12:35:38 +0100

since I may soon need to use truetype fonts, I am looking to replace my
current Type1/CID-only font lib with freetype. I quickly hacked some glue
code around freetype to switch from the current lib and it worked fine.

I had however a problem when I tried to optimize the interface with my
application. This app is multithreaded and run on multi-processor machines.
In order to run at full speed, several threads needs to be able to
simultaneously render the same glyph from the same font at different sizes.
The font is loaded once and put in a cache (the glyphs too, of course). The
font is basically read-only data. Each thread then have its own "working
memory" & size info it pass to the font library API used to render a glyph.
I need to do this because :
*there can be a lot of threads and having fonts loaded multiple times will
require too much memory and decrease performances instead of using a common
read/write-locked huge cache
*rendering glyphs and copying them is basically the only work done by the
threads (they are writing a printing dataflow to bitmaps). Having a mutex on
the library or fonts will waste lot of cpu time, even if the cache have a
good hit/miss ratio (specially with eastern fonts where the ratio is always
lower)

How can I do that with Freetype ? The size info and the glyph slot seems to
be tied to the loaded font and the rendering pipeline doesn't look fully
reentrant. What is exactly the actual reentrance degree of freetype ? :
*library-level (simultaneous rendering from different fonts)
*font-level (simultaneous rendering of different glyphs from same font)
*glyph-level (simultaneous rendering of same glyph from same font)
And, if not reentrant, is there a lot of work to make it so, down to
glyph-level ?






reply via email to

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