bug#43177: Bug: Emacs 27.1 hangs forever in `FcCharSetSubtractCount' from '/usr/lib/libfontconfig.so.1'

[Robert Pluim]

>>>>> On Thu, 03 Sep 2020 21:24:24 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Andreas Schwab <schwab@linux-m68k.org>
    >> Cc: Robert Pluim <rpluim@gmail.com>,  43177@debbugs.gnu.org,
    >> emacs@Alexander.Shukaev.name
    >> Date: Thu, 03 Sep 2020 19:51:17 +0200
    >> 
    >> On Sep 03 2020, Eli Zaretskii wrote:
    >> 
    >> > Do we understand why including the x backend produces such a huge
    >> > delay?  Where is most of that time spent, and why?
    >> 
    >> My guess would be that probing fonts via the x backend is expensive due
    >> to round trips to the X server (and the X server is quite busy during
    >> that time).

    Eli> If that is the reason, I guess we should try to minimize the number of
    Eli> fonts for which this is done.  Like, for example, set up some data
    Eli> structure to be consulted when a deciding whether a given font should
    Eli> be used with the x backend.  After all, the number of fonts for which
    Eli> that backend is needed is quite small, basically bitmapped fonts.

xfont_supported_scripts already skips opening a font if itʼs for
Japanese or Korean. Perhaps we should add tai-viet to that list?

<time passes>

Perhaps we should flip the default of scalable-fonts-allowed to nil
under GNU/Linux? [1]
(unless the only available font-backend is 'x', which can only happen
if the user explicitly sets it that way)?

Robert


Footnotes:
[1]  I only see that variable being checked in xfont.c, but ns-win.el
     refers to it, so I might have missed something.