On 2020-09-15 19:58, Rémi Bernon wrote:
On 2020-09-15 18:55, Nikolay Sivov wrote:
On 9/15/20 6:34 PM, Rémi Bernon wrote:
On 2020-09-15 16:12, Huw Davies wrote:
On Wed, Sep 09, 2020 at 12:21:57PM +0200, Rémi Bernon wrote:
This makes WineEngAddFontMemResourceEx, as well as the support for loading font face from memory in freetype.c, obsolete.
This doesn't seem ideal to say the least.
I'm also not convinced that using fontconfig to load the font info is necessarily the way to go. As you say, it's missing fontsig information and isn't available on all platforms.
Well, AFAICS loading fontsig isn't actually useful until we enumerate fonts, in which case it can be done lazily and (hopefully) unlikely to be triggered on all font faces.
Regarding fontconfig usage and availability, I think it's actually at the same time the cause of the performance problem, and its solution. It's not available on all platforms, but then we don't use it there anyway, and on other platforms there's an equivalent issue and solution with the corresponding platform font management API.
On Linux for instance, the vast majority of listed fonts actually come from fontconfig. However, instead of using its cached data, we take the hard way and re-parse everything with FreeType. This really feels wrong, and even if we could keep using that code path for the non-platform fonts, we should at least use fontconfig cached data to get the font face info.
We don't really have to create freetype objects to extract a small number of properties, we could read everything we need directly. You'll need this path anyway for fonts that don't come from fontconfig.
I also thought about that too, but there again I'm not sure if it's worth re-implementing something that these library already provide.
Especially if we end up doing mostly as bad as they do already. Is it really possible to improve the parsing time compared to FreeType? If fontconfig uses caches to store the font information, isn't it because it just takes a long time to parse font files (especially when there are many)?
So I did a quick try using dwrite opentype parsing code, and the parsing itself is probably fast enough. However, opening and mapping the font files using the Win32 API takes a long time, and it ends up being almost as slow as the FreeType parsing.
I suppose I will go down this route then, using open/mmap, as it seems indeed that we will be more accurate with the real font name tables. It will also allow us to get font signatures and keep the logic unchanged.