FreeType bashing
As many of you know, we are using FreeType as our font renderer. It is already able to produce very nice font renderings, but the quality of the rendering still seem to improve with every further version.
Until today, we were using FreeType in a wrong way, though. That didn't affect the rendering quality, but let the app_server crash pretty regularly (note, it still does that, but for different reasons and even a tiny bit less often 8-)). Somehow we assumed that FreeType was safe to be used in a multi-threaded environment. It even kind of is, but not in the way we used it.
FreeType provides an FT_Face object for every font face you are using - these objects are completely separated and can be used from different threads without worries. You just can't share one of these objects between several threads, and that's exactly what we were doing. Of course, that was a more or less stupid oversight on our behalf. But it's also a major pain that FreeType simply doesn't allow you to access a font face in a shared manner - it gives you a very easy to use API, but also a very limited one.
We just started discussing this topic in the app_server mailing list, so I don't know yet to what conclusion we'll come. We will probably need to introduce another abstraction layer between FreeType and our font sub-system, so that we can efficiently use FreeType without being locked in its single threaded design. Right now, I've introduced a per font face lock that might not even cover all uses of the object, but greatly lifts the situation.
If you know FreeType well, and feel that I missed something looking at the API it provides, feel free to tell me :-)
6 Comments:
I don’t really know very much of anything, but I was curious about this situation, and I ran accross the FAQ for Freetype 1.x. Question 24 makes it seem like Freetype was at least headed toward overhauling their system to be multi-threaded and reentrant at some point. I would have thought that since this is the FAQ for the 1.x series, and the current release is 2.1.10, that the implimentation would have been finished.
Well, as I said, you can use FreeType in multi-threaded apps - that was obviously not possible for the 1.x version.
It's just not usable in a good way, due to API limitations.
How about a split of the freetype codebase? As in a version that is made to work the way beos multithreading requires. Then at a later date if the freetype group can decide if they want to merge the codebases. Not sure about how much work that would be.
Can you have more than one FT_Face instances for the same font face?
Then you can implement AllocateFT_Face/ReleaseFT_Face functions
that will create a new FT_Face object if the other ones are in use(locked and not yet released). ReleaseFT_Face will store the object for later reuse.
No need for abstraction layers.
Then further improvements of the FT library may be geared towards sharing as much data as possible between the FT_Face instances.
When I would start hacking in FreeType directly, I could do something like this, yes.
I don't know how their memory management works, as that's what matters there.
The ideal solution would be to have different glyph slots per face (and size) - the face itself is read-only anyway.
To rephrase a famous quote:
"CS is the only field of science in which another level of abstraction is considered a solution"
Post a Comment
<< Home