GNU bug report logs -
#43177
Bug: Emacs 27.1 hangs forever in `FcCharSetSubtractCount' from '/usr/lib/libfontconfig.so.1'
Previous Next
Full log
View this message in rfc822 format
>>>>> On Thu, 03 Sep 2020 21:24:24 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, 43177 <at> debbugs.gnu.org,
>> emacs <at> 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.
This bug report was last modified 4 years and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.