I used fontconfig 2.12.4.
I noticed the following AFTER I sent the initial patch. I seriously
doubt that this is new or unexpected behavior since the frc member
unicodep is used to catch the individual rune that a font was opened
for (and then eliminate that ONE rune from a new open on the next
cache search pass). "break;"
The problem with this is - outside of the odd Emoji - when dealing
with Asian languages, if Glyphs can't be found it's because someone is
looking at a document that expects to have runes in the Asian Extended
D or E Unicode ranges, and they don't have that font available (in
monospace). That means occurrences of repeating, not-found runes are
going to be much less common than new, unique not-found runes, and
those font slots QUICKLY run out.
Maybe ALSO dealing with the ever-growing list of rune-not-found is the
right way to handle this situation (it will cut down on
open-then-close), by expanding this patch or in a completely separate
patch. The problem is a growing list of not-found makes for code that
sucks (using ever more memory over time). wchar_t isn't huge, but
these Unicode ranges are particularly large.
Thank you,
Gary Allen
On Mon, Oct 2, 2017 at 2:37 PM, Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
> On Sun, Oct 01, 2017 at 06:09:00PM -0400, Gary Allen Vollink wrote:
>> Patch partially addresses this question from last month:
>> https://lists.suckless.org/dev/1708/32111.html
>>
>> If a Glyph simply does not exist within the fonts of a system,
>> fontconfig ends up returning the original default font again. At this
>> point, 'st' happily opens it again, and holds a new frc array slot
>> hostage with a duplicate opened font in the array. Same glyph, it
>> won't happen again, but for a different glyph that doesn't exist,
>> things get really crazy with opens and closes (especially once the
>> hard-coded 16 fallback cache limit is reached). Under a certain mix
>> of legitimate fonts on the screen, it's possible to close a font that
>> is actually being used (This never works out well).
>>
>
> This sounds like a fontconfig bug or not? Which version of fontconfig do
> you use?
>
>> I attached a fairly simple diff that stops this.
>>
>> Check-in comment:
>> If fontconfig returns a font that has no matching glyph, close the now
>> opened, unused font.
>>
>> I first started to investigate a problem under macOS that happens
>> because macOS actually has a fallback font. There, once any single
>> Glyph cannot be found at all, no other Glyph that had not already been
>> loaded will ever be looked up. This, because the loaded fallback font
>> will ALWAYS return a positive Glyph. In addition to the fix attached,
>> the fix for this under macOS seems to be in .fonts.conf, so I won't
>> bother with further details. (Feel free to reach out off-list if you
>> want more info).
>>
>> Thank you,
>> Gary Allen
>
>> --- a/x.c 2017-09-30 15:46:51.713848500 -0400
>> +++ b/x.c 2017-10-01 16:59:13.786729400 -0400
>> _AT_@ -1100,8 +1100,13 @@
>>
>> glyphidx = XftCharIndex(xw.dpy, frc[frclen].font, rune);
>>
>> - f = frclen;
>> - frclen++;
>> + if (!glyphidx) {
>> + XftFontClose(xw.dpy, frc[frclen].font);
>> + frc[frclen].unicodep = 0;
>> + } else {
>> + f = frclen;
>> + frclen++;
>> + }
>>
>> FcPatternDestroy(fcpattern);
>> FcCharSetDestroy(fccharset);
>
>
> --
> Kind regards,
> Hiltjo
>
Received on Tue Oct 03 2017 - 04:06:55 CEST