On Tue, Feb 23, 2021 at 2:22 PM Matthias Clasen
<matthias.clasen@xxxxxxxxx> wrote:
> Our thoughts on improving this generally revolve around doing less work up front.
> Basically, switch to an incremental sorting approach, where Pango can ask for the
> "next best" font, one at a time.
But we need to go through all the fonts to get the first "best" font
and the result depends on the pattern. Apparently the idea was denied
at that bug though, heuristically pre-sorting fonts with most common
patterns like families and/or sizes might help in most cases because
the problem appears only when a lot of fonts are available on the
system.
This performance issue obviously appears after variable fonts. if we
have one more internal state to deal with it as single typeface (also
for non-VF fonts ideally), we might be able to reduce the targeted
fonts going through for (pre-)sorting. I mean the process extracting a
real FcPattern for VF at the caching time at the moment moves after
sorting. current cache system may needs to be revised though.
> In a recent call, Behdad pointed out a related, but distinct issue with the current
> pipeline approach to font rendering, as implemented in pango:
>
> First, pick fonts for all characters ("itemize")
> Second, select glyphs for the resulting runs ("Shape")
>
> The first step is where we use fontconfig to find candidate fonts, and then we
> check their coverage for each character to make a choice. fontconfig currently uses
> freetype to determine coverage information for fonts.
>
> But what characters are reasonably 'covered' by font very much depends on what use
> the second step makes of the font. The harfbuzz shaper can decompose and compose
> glyphs and thereby extend coverage in ways that freetype has no idea about.
>
> There are different ways in which this could be improved. One would be to give up
> on the approach of making all font selection choices up-front, and instead use a recursive
> approach in which the shaper can ask for more fonts if it can make do with the ones it
> was given initially.
>
> Another, maybe simpler approach would be to make fontconfig use harfbuzz instead
> of freetype for finding font coverage.
I'm fine with it if it would improves something but is it really
effectively representable in FcPattern?
>
> Matthias
> _______________________________________________
> Fontconfig mailing list
> Fontconfig@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/fontconfig
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig
