Thanks for the detailed response.
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.
I fully understand it was 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.
But that doesn't have to be the case. For example, HarfBuzz could always be compiled with HB_NO_MT to remove all that overhead. See hb-atomic.hh We even enable that in our HB_TINY configuration. See CONFIG.md and hb-config.hh.
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.
I'm not convinced that you lose *any* efficiency within the model that I propose. I hold HarfBuzz to the same if not more extreme standards and we have pretty much always been able to find a solution without compromising. We continue to do that. In fact, last night I started a major overhaul of the codebase.
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).
Umm. I removed all of those a few years ago. Again, without any side effect.
And as far as I know, this has always been pointed out explicitly in the FT_Library documentation.
Yeah I'm not claiming any of it is a surprise (there was one surprise I ran into the other day that I'll write about separately).
I understand that if you expected otherwise, you may have been disappointed (to keep it politely).
I came to this field with zero expectations. Everything I learned was from how people in projects large and small needed to show text.
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.
If you wish so. I'm not crazy about words. :-)
Thus there is no way to "fix all thread-safety" issues in it, without changing the internals and the API tremendously.
Agree about the internals, but not the API. I think new API can be added and old API kept. It will be a complete overhaul, I agree, but then again, the project is way overdue for one. So I'm suggesting that instead of a freetype3 that has incompatible ABI, just evolve freetype2 into freetype3, and freetype4, ... and remove old cruft after ten years or twenty years or never. That's what I'm leaving HarfBuzz with.
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.
In twenty years I never ran into *any* FreeType client who would get anywhere like configuring anything like that. If they did, they'd just modify the source.
Again, I understand everything I point out can be countered with a "some might need". That's a difference in library design philosophy.
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.
Again, if there was a mission statement to FreeType, we could deduce whether that should remain a goal.
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.
We agree on the root cause indeed.
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).
That is *exactly* what I've done in hb-ft.cc. But is too fragile & too slow. So I keep moving on. What you are saying basically is that every piece of code sharing an FT_Face or FT_Library needs to synchronize together. A clear corollary of that is that FT_Face has no place in any library's API. Indeed, that's the direction we have been heading. At which point it just becomes easier to reimplement everything somewhere else.
I can't tell you which way is best. It would be interesting to discuss which properties these "thread-safe font objects" could have.
Sure. I can suggest based on my current experience with other libraries.
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.
I think we are heading towards writing a sane and small library instead of FreeType, not on top of.
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.
To make it clear, the only parts of FreeType which have no better open source equivalent are all the hinting engines: autohinter, bytecode interpretter, and CFF hinter. There's nothing else left. When we eventually get to fix and publish the outline-extraction API in HarfBuzz, I'm confident that the essence of those three modules can be lifted and reimplemented as external components using the HarfBuzz API.
- David
[1] Except if each thread has its own FT_Library instance (and corresponding set of FT_Face/FT_Size/FT_GlyphSlot objects.
That's what Pango currently does. But not even then because we don't want to restrict clients from eg. doing layout on one thread and use it on another.
b
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
--