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

[Rémi Bernon]

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)?

>>
>> On other systems where fontconfig isn't available, we probably have
>> the same issues and the same solutions. On macos for instance,
>> although I've got limited knowledge, we use Carbon to list fonts, but
>> then take the hard way too instead of using dedicated functions to
>> access font family and face names [1] (which hopefully is cached by
>> the system too).
>>
>> [1] https://developer.apple.com/documentation/coretext/ctfont-q6r
>>
>> On Android, we just enumerate the system fonts the hard way anyway,
>> but maybe there's some better there too, or fontconfig could perhaps
>> be ported there.
>>
>> In any case, as long as there's only a few platform fonts, the
>> fallback code with registry cache is probably still good enough, and
>> we have to have it anyway in case none of the above is supported.
>> Making the non-platform font listing also go the specialized font code
>> can make things even a little bit faster, but it's not really necessary.
>>
>> And I don't like however the idea of re-implementing a font cache and
>> make everything use it instead, especially since it still takes time
>> to initialize when empty, fc-cache (or the platform font management
>> API) has probably already done it, and then cache management is hard
>> to get right, especially since we need it to be persistent to make it
>> really useful.
> Is it possible to get everything we need from fc-cache? I don't believe
> that's the case for directwrite for example. For instance for names
> strings you'll have to prioritize by encoding/platform, and that most
> likely differs between fontconfig and windows.
> 

It provides high-level names, but all declared font names are there, 
with the corresponding language, encoded in UTF-8. Mapping it to the 
Windows equivalent isn't exactly immediate but I think it's doable with 
a few heuristics.

Maybe it's not accurate enough then, but gdi32 match_name_table_language 
seemed a little fuzzy, so it didn't look like it would matter too much. 
For platform provided fonts I would expect (perhaps incorrectly) font 
names to be roughly normalized.

Then I also don't know what we exactly need.

> We should obviously continue to use fontconfig for initial font
> discovery, and maybe for some fallback cases that we don't currently
> have, I think fontconfig is capable of specifying preferred font per
> language or script, which is again not exactly what we need.
>>
>>> Did you look at a delayed initialisation approach?  That could
>>> potentially use an out-of-process server.
>>>
>>
>> I'm not sure if it's possible to make it lazy and right at the same
>> time. Don't we have to list system fonts and update the registry
>> entries on startup, so any application listing the registry could get
>> an up to date font list even if they don't use gdi32?
>>
>> The staging patch does the lazy initialization, and although I haven't
>> checked that specific example, I have a hunch that it's broken there.
>> I may be wrong, or maybe not having the registry up to date on startup
>> isn't a big issue?
>>
>> Cheers,
> 
> -- 
Rémi Bernon <rbernon at codeweavers.com>