@Brecht Van Lommel (brecht) - Is there something we can do about the performance impact noted in D12622?

Not that I have found yet. Removing everything we do doesn't seem to reduce the time in any noticeable way. Using memory-mapping helps slightly but probably not enough to be worth it. But still investigating.

As a test, mostly for you, I made D15258: BLF: Fonts with FT_Face Optional which loads the fonts fully initially to gather data like the coverage, but then immediately drops the Face. It is only added again when actually needed, so remove the overhead for fonts that are not used by users.

Or worst case, we could cache unicode ranges outside the font files?

We could have a font.config or similar for something like this if it helps. Could hold those overage bits, allow ordering. Not sure it that is interesting.

I'm also hesitant about including material symbols...

No problem removing them from this. I just liked having everything in here for testing and showing off.

In D15235#411686, @Harley Acheson (harley) wrote:

Not that I have found yet. Removing everything we do doesn't seem to reduce the time in any noticeable way. Using memory-mapping helps slightly but probably not enough to be worth it. But still investigating.

As a test, mostly for you, I made D15258: BLF: Fonts with FT_Face Optional which loads the fonts fully initially to gather data like the coverage, but then immediately drops the Face. It is only added again when actually needed, so remove the overhead for fonts that are not used by users.

It's better for memory usage, but does not address startup time.

Or worst case, we could cache unicode ranges outside the font files?

We could have a font.config or similar for something like this if it helps. Could hold those overage bits, allow ordering. Not sure it that is interesting.

We could just put the full list of bundled fonts + their unicode ranges in the code. Probably that's the easiest solution unless we find some way to make font loading faster.

@Brecht Van Lommel (brecht) - We could just put the full list of bundled fonts + their unicode ranges in the code. Probably that's the easiest solution unless we find some way to make font loading faster.

Interesting. I think I see a solution there, but lets make sure we are talking about the same thing...

We'd need something like D15258: BLF: Fonts with FT_Face Optional, so we can have FontBLFs that do not have a loaded FT_Face.

But while loading the files we check their names. If found we know the details so we don't bother loading at all, just leave the face NULL unless needed. If NOT found then we load, read details, then drop. That would work to be superfast for the things we ship, not have any overhead for unused files, but still allows users to add their own

Yes, exactly.

In D15235#411973, @Brecht Van Lommel (brecht) wrote:

Yes, exactly.

@Ray Molenkamp (LazyDodo) was suggesting I could make a codegen to gather this information on our released fonts at build time. Does that sound interesting or messy?

Personally I would not bother, we're not changing fonts that often. Doesn't seem worth adding complexity and potential for failures to the build system.

only print report of missing characters if DEBUG