[PATCH 1/8] gdi32: Implement AddFontMemResourceEx with temp files.
Rémi Bernon
rbernon at codeweavers.com
Tue Sep 15 10:34:33 CDT 2020
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.
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.
> 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>
More information about the wine-devel
mailing list