[PATCH 1/8] gdi32: Implement AddFontMemResourceEx with temp files.

[Rémi Bernon]

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.
-- 
Rémi Bernon <rbernon at codeweavers.com>