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 <hil...@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 >> @@ -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 >
