Hi David,
I've been meaning to reply to your request but the list of things I wanted to communicate kept growing exponentially and so I have not been able to say.
But here, from a technical perspective this is my biggest issue, which you can also see as a roadmap:
Thanks for the link Bhedad, this gives useful history about your woes and considerations. I'd like to address some of these here.
First of all, the reason why FreeType has never been designed to be "thread-safe" (in the sense where it supports multiple threads operating on its objects concurrently [1]) is entirely and very very intentional.
The library was designed, first and foremost to be as efficient as possible on embedded systems with limited memory and operating system primitives.
Any kind of thread-safety scheme, even atomic refcounts, would have been detrimental to its portability, and most likely performance.
Reducing memory usage means using in-place modification of existing objects and aggressive caching of state within various objects under a root FT_Library instance.
That's why we have FT_Size and FT_GlyphSlot objects, very visible in the API, but there are also various levels of caching internally (most of them simple LRU lists that only change occasionally, but still a potential source of thread races).
And as far as I know, this has always been pointed out explicitly in the FT_Library documentation.
I understand that if you expected otherwise, you may have been disappointed (to keep it politely). However I do not consider the API to be "broken" regarding thread-safety, it's just not designed for this use case, at all. It solves a very different problem.
Thus there is no way to "fix all thread-safety" issues in it, without changing the internals and the API tremendously. You may have made some modifications to the library to get rid of the most annoying thread-related issues you've encountered,
but I assure you there are still by-design thread-races in many places. Also, some of the fixes seem a little dubious, i.e. the raster pool is now a fixed 16 kiB now, while it used to be resizable by the user.
This was useful when rendering large vector graphics (not fonts) with the FreeType rasterizers. Now the algorithm are essentially quadratic, which makes it painful or unusable for this use case.
The root of your problem seems to be a vast impedance mismatch between the Cairo / Pango / Harfbuzz APIs which expect, or encourage, several threads (probably from clients, which would be worse) to use FT_Face objects liberally.
This simply cannot work reliably.
My only immediate recommendation would be to use a different "face" abstraction object for these, that would either reimplement FreeType, or parts of it (the route Pango seems to have chosen), or wrap FreeType objects behind the right amount of
caching and thread-specific synchronization to make it work (like other libraries like Skia do). I can't tell you which way is best. It would be interesting to discuss which properties these "thread-safe font objects" could have.
Maybe we can write a sane and small library on top of FreeType to provide just that. I just don't think there is a way to do that within it.
Another alternative would be to refactor the FreeType library considerably into a new version (with a different thread-safe API where it matters), but that's a far harder problem, is likely to result in something that will be larger, more complex internally, use more memory, and likely be slower.
At least we could rewrite the internals with a better language than C89 :) But I'd rather have an extensive unit-test and regression test suite before trying this.
- David
[1] Except if each thread has its own FT_Library instance (and corresponding set of FT_Face/FT_Size/FT_GlyphSlot objects.
I will keep trying to comment on the two GSoC projects, and eventually get to write about the health of the freetype as a community project.
Cheers,
behdad
Hello freetype-devel@ list members,
It's been a
very very long time, but I have some free time in the coming weeks to
work on FreeType. Werner invited me to write a small announcement here and I'm currently looking at the official bugs list.
I'd like to know what are, in your opinion, the most pressing issues to work on at that point?
Apart from that, I had the following things in mind:
-
Improving / refactoring the build system a little. E.g. it should be
possible to simplify the
rules.mk/module.mk files considerably, and auto-generate most of the Makefiles / Jamfiles / CMakefiles
from a single source of truth (exact format to be defined), at least the
parts that deal with the headers / sources / configuration headers and the module dependencies.
-
Improve testing (unit and regression tests to be exact) There are lots
of possibilities here, and it will probably better to do this in small
incremental steps.
Voila, I'd be happy to read your suggestions, Happy to be here.
- David Turner
--