GNU bug report logs -
#19266
24.4; Font-related window redrawing delays on OS X
Previous Next
Reported by: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
Date: Thu, 4 Dec 2014 07:14:01 UTC
Severity: normal
Tags: moreinfo
Found in version 24.4
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19266 in the body.
You can then email your comments to 19266 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 07:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kirill Ignatiev <kirill.ignatiev <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 04 Dec 2014 07:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[bugreport.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 07:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 4 Dec 2014 02:13:30 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>
> [This is a copy of this question on Emacs.SE:
> http://emacs.stackexchange.com/questions/4061]
> At least one other person has the same problem.
Please ask those persons to report here directly, and to read the
responses and discussions.
> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> in languages like haskell, julia or c++), and (I think) especially with
> an ornate color theme, I experience delays of maybe about five seconds
> when switching between buffers. Running emacs under lldb show a stack
> trace below; I get a similar stack trace from running `emacs -Q` and
> typing `C-h h` (`view-hello-file`), which takes quite a while to display
> the hello file.
AFAICT, these delays are due to Emacs searching the system for
appropriate fonts needed to display those unusual symbols.
> What can I do about these window redrawing delays? I am not sure what I
> have misconfigured.
Optimize your font configuration, so that the font search becomes
faster.
> Does emacs reload all fonts every time I switch to a different frame or
> buffer? It also seems to have a delay sometimes when a previously
> invisible overlay is shown.
Emacs only looks for a font when it needs to display something. when
previously invisible portion is about to be displayed, Emacs needs the
fonts to display it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 07:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 19266 <at> debbugs.gnu.org (full text, mbox):
On 4 December 2014 at 02:30, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Thu, 4 Dec 2014 02:13:30 -0500
>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>>
>> [This is a copy of this question on Emacs.SE:
>> http://emacs.stackexchange.com/questions/4061]
>> At least one other person has the same problem.
>
> Please ask those persons to report here directly, and to read the
> responses and discussions.
>
>> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
>> in languages like haskell, julia or c++), and (I think) especially with
>> an ornate color theme, I experience delays of maybe about five seconds
>> when switching between buffers. Running emacs under lldb show a stack
>> trace below; I get a similar stack trace from running `emacs -Q` and
>> typing `C-h h` (`view-hello-file`), which takes quite a while to display
>> the hello file.
>
> AFAICT, these delays are due to Emacs searching the system for
> appropriate fonts needed to display those unusual symbols.
I understand that this needs to happen once. Is it reasonable that the
delay happens many times during normal editing?
The description of what triggers the delays is unclear because for me
it's only reproducible incidentally, during normal work. I have
fold-mode that hides large portions of text, and a number of frames.
If I hide some previously-displayed text, go work in another frame,
then come back and unhide the text, then there is the font-searching
delay. Something similar happens if I switch to a different buffer,
then some time later switch back.
>> What can I do about these window redrawing delays? I am not sure what I
>> have misconfigured.
>
> Optimize your font configuration, so that the font search becomes
> faster.
>
>> Does emacs reload all fonts every time I switch to a different frame or
>> buffer? It also seems to have a delay sometimes when a previously
>> invisible overlay is shown.
>
> Emacs only looks for a font when it needs to display something. when
> previously invisible portion is about to be displayed, Emacs needs the
> fonts to display it.
The reason I suspect this may be an actual bug is not that the delay
happens at all, but rather that it happens quite often, and the text
that causes the search for fonts used to be displayed only a short
time ago.
That said, I'm not familiar with how emacs manages fonts. Is it
reasonable to expect to keep all recently used fonts in memory and not
search for them again?
Thanks for the very quick reply.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 08:04:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 4 Dec 2014 02:41:34 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> Cc: 19266 <at> debbugs.gnu.org
>
> > AFAICT, these delays are due to Emacs searching the system for
> > appropriate fonts needed to display those unusual symbols.
>
> I understand that this needs to happen once.
It can happen once for each portion of a buffer that was not yet
displayed.
> The description of what triggers the delays is unclear because for me
> it's only reproducible incidentally, during normal work. I have
> fold-mode that hides large portions of text, and a number of frames.
> If I hide some previously-displayed text, go work in another frame,
> then come back and unhide the text, then there is the font-searching
> delay. Something similar happens if I switch to a different buffer,
> then some time later switch back.
Emacs releases unused font slots from time to time, which might be the
reason here.
But this is speculation; a reproducible recipe is required to
investigate and come up with specifics. And yes, it could be a bug.
> Is it reasonable to expect to keep all recently used fonts in memory
> and not search for them again?
For some value of "recently", yes. Again, more data is needed to
determine whether this is an Emacs bug or a system configuration
issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 08:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 19266 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 4 December 2014 at 03:03, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Thu, 4 Dec 2014 02:41:34 -0500
>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>> Cc: 19266 <at> debbugs.gnu.org
>
> Emacs releases unused font slots from time to time, which might be the
> reason here.
>
> But this is speculation; a reproducible recipe is required to
> investigate and come up with specifics. And yes, it could be a bug.
Okay, here's one attempt to reproduce it (sorry about the length). The
idea is to view lots of files, then later viewing a buffer that was
previously displayed causes a delay.
1. Start with -Q.
2. Open file uncommon_symbols.txt (attached). There's a delay but it opens fine.
3. Select the entire file; there is another delay (presumably font for
selected region is loaded separately).
4. C-h h to view hello file. Scroll all the way down with C-v.
5. Mark entire hello file, scroll all the way up from bottom.
6. View src/font.c (in emacs source), scroll all the way down to
render the whole file.
7. Mark the entire file, scroll all the way up, to view the entire
file in selected color.
Now:
8. View uncommon_symbols.txt: no delay.
9. Mark the entire file: no delay again.
10. View hello file: there is a noticeable delay of a few seconds with
the stack trace attached below.
This delay is, I think, identical to what I sometimes experience. Also
the reproduction's length can maybe be reduced somehow. I don't think
viewing three unicode-rich files should lead to such a noticeable
redrawing delay.
It's not so much that the delay is terribly long, it's that it
interrupts typing and normal workflow.
[uncommon_symbols_bt.txt (text/plain, attachment)]
[uncommon_symbols.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 09:56:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Am 04.12.2014 um 08:30 schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
>> Date: Thu, 4 Dec 2014 02:13:30 -0500
>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>>
>> [This is a copy of this question on Emacs.SE:
>> http://emacs.stackexchange.com/questions/4061]
>> At least one other person has the same problem.
>
> Please ask those persons to report here directly, and to read the
> responses and discussions.
So here I am. How do I subscribe to this bug so that I get replies per mail?
>> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
>> in languages like haskell, julia or c++), and (I think) especially with
>> an ornate color theme, I experience delays of maybe about five seconds
>> when switching between buffers. Running emacs under lldb show a stack
>> trace below; I get a similar stack trace from running `emacs -Q` and
>> typing `C-h h` (`view-hello-file`), which takes quite a while to display
>> the hello file.
>
> AFAICT, these delays are due to Emacs searching the system for
> appropriate fonts needed to display those unusual symbols.
>
>> What can I do about these window redrawing delays? I am not sure what I
>> have misconfigured.
>
> Optimize your font configuration, so that the font search becomes
> faster.
I do not know about the OP, but I do not have any “font configuration”. All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts? Shouldn't Emacs pick reasonable defaults by itself, and remember them? I don't mean to blame anyone, but see, all other applications on my system work fine with my fonts…
>> Does emacs reload all fonts every time I switch to a different frame or
>> buffer? It also seems to have a delay sometimes when a previously
>> invisible overlay is shown.
>
> Emacs only looks for a font when it needs to display something. when
> previously invisible portion is about to be displayed, Emacs needs the
> fonts to display it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 10:19:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
> Date: Thu, 4 Dec 2014 10:55:21 +0100
> Cc: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>,
> 19266 <at> debbugs.gnu.org
>
> > Please ask those persons to report here directly, and to read the
> > responses and discussions.
>
> So here I am.
Thanks for responding.
> How do I subscribe to this bug so that I get replies per mail?
You will be CC'ed on responses, so no need to subscribe.
> > Optimize your font configuration, so that the font search becomes
> > faster.
>
> I do not know about the OP, but I do not have any “font configuration”. All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
I meant your system-wide font configuration, not what you do in Emacs.
> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?
Sorry, I don't know that. If you didn't install too many optional
fonts that didn't come with your system, then I think you are already
set. Otherwise, perhaps some OS X expert, here or on some other
forum, could help.
> Shouldn't Emacs pick reasonable defaults by itself, and remember them?
It should, and it tries to.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 04 Dec 2014 10:20:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Am 04.12.2014 um 11:17 schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
>> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
>> Date: Thu, 4 Dec 2014 10:55:21 +0100
>> Cc: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>,
>> 19266 <at> debbugs.gnu.org
>>
>>> Please ask those persons to report here directly, and to read the
>>> responses and discussions.
>>
>> So here I am.
>
> Thanks for responding.
>
>> How do I subscribe to this bug so that I get replies per mail?
>
> You will be CC'ed on responses, so no need to subscribe.
>
>>> Optimize your font configuration, so that the font search becomes
>>> faster.
>>
>> I do not know about the OP, but I do not have any “font configuration”. All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
>
> I meant your system-wide font configuration, not what you do in Emacs.
I don't have that either :) OS X comes with all sorts of fonts pre-installed, and I just added some five fonts or so.
>> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?
>
> Sorry, I don't know that. If you didn't install too many optional
> fonts that didn't come with your system, then I think you are already
> set. Otherwise, perhaps some OS X expert, here or on some other
> forum, could help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Sun, 07 Dec 2014 05:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 19266 <at> debbugs.gnu.org (full text, mbox):
I tried looking into this a bit more, and I'm not very familiar with
emacs's internals.
I find that many faces that were previously used get garbage collected
(I see macfont_close being called from cleanup_vector), but I don't
know how faces are stored, nor do I understand why they are no longer
referenced (common sense suggests that they should remain in memory as
long as the buffer that used them is still there). It seems that the
faces are not actively used for displaying the buffer, but can be
expected to be reused in a short time (e.g., region face or comment
face).
Can someone explain where faces are stored and why they are no longer
referenced, even though the buffer that used them is still active?
I am not sure if this is related to this bug, but there is a constant
CLEAR_FACE_CACHE_COUNT (=500) that causes face cache to be cleared
every 500 redisplays. Does anyone understand why this is really
necessary? If the fonts/faces are still in use, that seems wasteful,
unless I misunderstand something.
On 4 December 2014 at 05:19, Sebastian Wiesner <swiesner <at> lunaryorn.com> wrote:
>
>> Am 04.12.2014 um 11:17 schrieb Eli Zaretskii <eliz <at> gnu.org>:
>>
>>> From: Sebastian Wiesner <swiesner <at> lunaryorn.com>
>>> Date: Thu, 4 Dec 2014 10:55:21 +0100
>>> Cc: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>,
>>> 19266 <at> debbugs.gnu.org
>>>
>>>> Please ask those persons to report here directly, and to read the
>>>> responses and discussions.
>>>
>>> So here I am.
>>
>> Thanks for responding.
>>
>>> How do I subscribe to this bug so that I get replies per mail?
>>
>> You will be CC'ed on responses, so no need to subscribe.
>>
>>>> Optimize your font configuration, so that the font search becomes
>>>> faster.
>>>
>>> I do not know about the OP, but I do not have any “font configuration”. All that I do is `(set-frame-font "Source Code Pro-13" nil t)'.
>>
>> I meant your system-wide font configuration, not what you do in Emacs.
>
> I don't have that either :) OS X comes with all sorts of fonts pre-installed, and I just added some five fonts or so.
>
>>> Besides, I'm no font expert at all, so how am I supposed do “optimize” my fonts?
>>
>> Sorry, I don't know that. If you didn't install too many optional
>> fonts that didn't come with your system, then I think you are already
>> set. Otherwise, perhaps some OS X expert, here or on some other
>> forum, could help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Sun, 07 Dec 2014 16:10:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 7 Dec 2014 00:50:01 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 19266 <at> debbugs.gnu.org
>
> I find that many faces that were previously used get garbage collected
> (I see macfont_close being called from cleanup_vector), but I don't
> know how faces are stored, nor do I understand why they are no longer
> referenced (common sense suggests that they should remain in memory as
> long as the buffer that used them is still there).
Face realizations are not specific to buffers, they are specific to
frames. So the same face can be realized differently on each frame,
and the same buffer displayed on 2 different frames might look
differently.
OTOH, a given face can be used by many buffers on a frame.
So we cannot easily make a simple one-to-one connection between
buffers and faces they use.
> It seems that the faces are not actively used for displaying the
> buffer, but can be expected to be reused in a short time (e.g.,
> region face or comment face).
You forgot the 'default' face, by far the most reused face.
Also, Emacs consults the face every time it needs to display a
character which uses that face. So caching is really a necessity.
> Can someone explain where faces are stored and why they are no longer
> referenced, even though the buffer that used them is still active?
Realized faces are stored in the frame's face_cache. As for the
second part of your question, I hope I clarified the issue at least to
some extent.
> I am not sure if this is related to this bug, but there is a constant
> CLEAR_FACE_CACHE_COUNT (=500) that causes face cache to be cleared
> every 500 redisplays. Does anyone understand why this is really
> necessary?
Because we don't really know when a face is no longer needed.
Tracking that could be more hassle than throwing the cache away from
time to time.
Anyway, if you enlarge that number 100-fold, does the problem go away?
If not, then this is not the cause of your problem.
Also, font objects are stored and maintained differently than faces.
So I'm not sure you are on the right track looking into faces.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Wed, 10 Dec 2014 23:51:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 19266 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Can someone familiar with emacs' font internals check if this makes
sense as the cause of the problem, please? I really don't understand
how/where fonts are stored/cached/used; I did read
font/fontset/macfont/alloc.c, but I'm still unclear.
To summarize: My interpretation of what's happening is that when emacs
looks at some fonts to see if they contain a certain characters and
neither of them does, emacs *does not* cache the fonts. So the next
time redisplay happens after those fonts are garbage-collected, emacs
has to load the fonts all over again, causing a noticeable redisplay
delay.
Shouldn't these fonts be cached as well?
For testing, how do I turn off font garbage collection, so that no
font is ever closed?
How do I trigger font garbage collection manually?
Is this the right mailing list for this?
So now:
Apply the attached patch that traces every call to
font_driver->{open,close} with printf, *no actual changes*. I tested
this on OS X, maybe it's the same on linux. Now consider the following
commands, executed in patched emacs with -Q:
(set-fontset-font
t '(#x1d400 . #x1d7ff)
(font-xlfd-name (find-font (font-spec :family "Symbola"))))
(progn
(insert ?\n)
(dotimes (i (- #x1d800 #x1d400))
(insert (+ #x1d400 i)))
(insert ?\n))
Here, Symbola is a font that includes uncommon characters
#x1d400..#x1d7ff (not all of that range is valid unicode characters),
while the font chosen by emacs by default ("Menlo", there's nothing
special about it, I think) does not. On a different computer with different
fonts, you might need to set some other fonts.
For reference, the font specs are (from describe-fontset)
-*-Symbola-normal-normal-semicondensed-*-*-*-*-*-p-0-iso10646-1
-*-Menlo-normal-normal-normal-*-*-*-*-*-m-0-fontset-startup
This example uses invalid characters (rather than characters missing
from Symbola) because Symbola includes a lot of characters, and my
previous testing suggested that if I pick a font that actually misses
some characters the results are the same, but then I have to try to
also figure out which exact characters are missing, which is very
font-dependent. Invalid characters are always missing.
It seems to be those characters not present in either Symbola or the
default font that are causing delays.
I run emacs with -Q, and execute those two commands in the scratch
buffer. The output is this:
font_open_entity: 0x10280fe30 4336959717 0 => 4321797773
font_open_entity: 0x10280fe30 4322249501 12 => 4322240165
font_open_entity: 0x10280fe30 4322249381 12 => 4322313893
compact_font_cache_entry: dropped 2 entries
cleanup_vector: drv->close 0x101a026a0
font_open_entity: 0x10280fe30 4346667037 12 => 4346773157
font_open_entity: 0x10280fe30 4321497117 12 => 4322359973
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x101a146a0
font_open_entity: 0x10280fe30 4346850893 12 => 4346855205
font_open_entity: 0x10280fe30 4346855581 12 => 4338042813
font_open_entity: 0x10280fe30 4346864757 12 => 4347020349
font_open_entity: 0x10280fe30 4314058597 12 => 4314214573
font_open_entity: 0x10280fe30 4314313573 12 => 4314346005
font_open_entity: 0x10280fe30 4314342253 12 => 4314776629
font_open_entity: 0x10280fe30 4338539877 12 => 4338731989
font_open_entity: 0x10280fe30 4338728301 12 => 4315110181
font_open_entity: 0x10280fe30 4315102573 12 => 4338889725
font_open_entity: 0x10280fe30 4315401573 12 => 4315429429
font_open_entity: 0x10280fe30 4337120613 12 => 4339102261
font_open_entity: 0x10280fe30 4339702117 12 => 4339661005
font_open_entity: 0x10280fe30 4339664797 12 => 4339599381
font_open_entity: 0x10280fe30 4339591533 7 => 4315644109
compact_font_cache_entry: dropped 15 entries
The number of font_open_entity seems to correspond to the number of
different fonts on my computer matching the default font spec, or
something like this. None of them contain missing characters. Now I
go to, say, emacs/src/font.c, scroll up and down for a while (I'm not
sure how this garbage collection is triggered, I'd rather trigger it
manually but I don't know how), and eventually I get this:
font_open_entity: 0x10280fe30 4347168317 12 => 4347168797
font_open_entity: 0x10280fe30 4347168557 12 => 4347247269
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x1013b80c8
cleanup_vector: drv->close 0x102a9f8c8
cleanup_vector: drv->close 0x102a90810
cleanup_vector: drv->close 0x102a17230
cleanup_vector: drv->close 0x101383a30
cleanup_vector: drv->close 0x1029e33f8
cleanup_vector: drv->close 0x101335b20
cleanup_vector: drv->close 0x1029bcbd0
cleanup_vector: drv->close 0x1012e4430
cleanup_vector: drv->close 0x10127b210
cleanup_vector: drv->close 0x10125b0a8
cleanup_vector: drv->close 0x1029147b8
cleanup_vector: drv->close 0x1031a4438
cleanup_vector: drv->close 0x10317bf20
cleanup_vector: drv->close 0x101a1faa0
cleanup_vector: drv->close 0x103167ea0
This looks (?) like the fonts that don't contain the characters
missing from "Symbola" (which are invalid, so they can be expected to
be missing) and that emacs looked through, are garbage-collected.
Now I go back to the scratch buffer, and see this in the output:
font_open_entity: 0x10280fe30 4313918837 12 => 4322005021
font_open_entity: 0x10280fe30 4347261093 12 => 4347020349
font_open_entity: 0x10280fe30 4315110293 12 => 4346845997
font_open_entity: 0x10280fe30 4346846261 12 => 4346946861
font_open_entity: 0x10280fe30 4346947125 12 => 4322621621
font_open_entity: 0x10280fe30 4322621885 12 => 4314086573
font_open_entity: 0x10280fe30 4314086837 12 => 4314116149
font_open_entity: 0x10280fe30 4314111805 12 => 4314181685
font_open_entity: 0x10280fe30 4314181949 12 => 4314333237
font_open_entity: 0x10280fe30 4314000621 12 => 4314399253
font_open_entity: 0x10280fe30 4314399517 12 => 4314468405
font_open_entity: 0x10280fe30 4314465117 12 => 4314653901
font_open_entity: 0x10280fe30 4314649741 12 => 4314723381
font_open_entity: 0x10280fe30 4314715909 7 => 4314724005
compact_font_cache_entry: dropped 14 entries
The redisplay to go back to the scratch buffer takes a fair amount of
time (several seconds), and it looks like the fonts that don't contain
missing characters are loaded again, examined, and they still don't
contain those characters.
The rest of the session looks like this, where I did some editing.
font_open_entity: 0x10280fe30 4314826397 12 => 4314833973
font_open_entity: 0x10280fe30 4314822261 12 => 4338334365
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x1012d7430
cleanup_vector: drv->close 0x1012d76a0
cleanup_vector: drv->close 0x1012c64c8
cleanup_vector: drv->close 0x101299030
cleanup_vector: drv->close 0x101288210
cleanup_vector: drv->close 0x101278030
cleanup_vector: drv->close 0x101253030
cleanup_vector: drv->close 0x101243030
cleanup_vector: drv->close 0x10123bca8
cleanup_vector: drv->close 0x101a5f8b0
cleanup_vector: drv->close 0x103192528
cleanup_vector: drv->close 0x1031dbaa0
cleanup_vector: drv->close 0x1031c8818
cleanup_vector: drv->close 0x1031a4438
cleanup_vector: drv->close 0x103179b28
cleanup_vector: drv->close 0x1019c9018
font_open_entity: 0x10280fe30 4338666765 12 => 4338670133
compact_font_cache_entry: dropped 1 entries
cleanup_vector: drv->close 0x10295ba98
cleanup_vector: drv->close 0x1012f2430
font_open_entity: 0x10280fe30 4338678941 14 => 4338683037
font_open_entity: 0x10280fe30 4338691229 12 => 4338695325
font_open_entity: 0x10280fe30 4338691349 12 => 4338715805
font_open_entity: 0x10280fe30 4338687245 10 => 4338471477
font_open_entity: 0x10280fe30 4338740325 12 => 4338744093
font_open_entity: 0x10280fe30 4338687245 7 => 4314561589
font_open_entity: 0x10280fe30 4338687365 12 => 4314566357
compact_font_cache_entry: dropped 3 entries
[bugreport2_patch.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Thu, 11 Dec 2014 17:46:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 10 Dec 2014 18:50:01 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> Cc: Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
>
> Can someone familiar with emacs' font internals check if this makes
> sense as the cause of the problem, please? I really don't understand
> how/where fonts are stored/cached/used; I did read
> font/fontset/macfont/alloc.c, but I'm still unclear.
Unfortunately, we don't have too many experts on this, to put it
mildly. Dmitry, could you please take a look?
> To summarize: My interpretation of what's happening is that when emacs
> looks at some fonts to see if they contain a certain characters and
> neither of them does, emacs *does not* cache the fonts. So the next
> time redisplay happens after those fonts are garbage-collected, emacs
> has to load the fonts all over again, causing a noticeable redisplay
> delay.
This does sound like the truth, although I'm not sure.
> For testing, how do I turn off font garbage collection, so that no
> font is ever closed?
Comment out the call to cleanup_vector?
> How do I trigger font garbage collection manually?
Did you try "M-x garbage-collect RET"?
> Is this the right mailing list for this?
Yes, it is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Fri, 12 Dec 2014 02:11:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 19266 <at> debbugs.gnu.org (full text, mbox):
On 11 December 2014 at 12:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>> Cc: Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
>
> Comment out the call to cleanup_vector?
Oops, I only tried to turn compact_font_cache_entry into a noop. But
neither that, nor doing nothing in cleanup_vector works. If I comment
out drv->close, I see a bunch of calls to drv->close not being made,
but new fonts are *still* being opened in font_open_entity.
I'm guessing that when fonts are garbage collected, they are already
genuinely discarded, not pointed to from elisp structures (or where
they are stored), and are genuine garbage. Do you know where the
pointers to fonts live? I haven't figured out where they are being
discarded, and I'd like to stop them from becoming garbage in the
first place.
>
>> How do I trigger font garbage collection manually?
>
> Did you try "M-x garbage-collect RET"?
Yes, but it doesn't seem to trigger closing fonts. Perhaps there is
some other process at work there?
Thanks for your help, these redrawing delays are really irritating.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Fri, 12 Dec 2014 08:07:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 11 Dec 2014 21:10:32 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
>
> On 11 December 2014 at 12:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Date: Wed, 10 Dec 2014 18:50:01 -0500
> >> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> >> Cc: Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
> >
> > Comment out the call to cleanup_vector?
>
> Oops, I only tried to turn compact_font_cache_entry into a noop. But
> neither that, nor doing nothing in cleanup_vector works. If I comment
> out drv->close, I see a bunch of calls to drv->close not being made,
> but new fonts are *still* being opened in font_open_entity.
>
> I'm guessing that when fonts are garbage collected, they are already
> genuinely discarded, not pointed to from elisp structures (or where
> they are stored), and are genuine garbage. Do you know where the
> pointers to fonts live? I haven't figured out where they are being
> discarded, and I'd like to stop them from becoming garbage in the
> first place.
Look up the call chain (best done by setting a breakpoint and looking
at the backtrace), and you will certainly find a place which decides
to discard them. Then comment out or change the code which does that.
> >> How do I trigger font garbage collection manually?
> >
> > Did you try "M-x garbage-collect RET"?
>
> Yes, but it doesn't seem to trigger closing fonts. Perhaps there is
> some other process at work there?
Again, look at the backtrace at a breakpoint in cleanup_vector and in
compact_font_cache_entry. Isn't there some GC-related function on the
callstack? Perhaps post that here, if you cannot figure that out.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Fri, 12 Dec 2014 08:31:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Am 12.12.2014 um 03:10 schrieb Kirill Ignatiev <kirill.ignatiev <at> gmail.com>:
>
> On 11 December 2014 at 12:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>>> Cc: Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
>>
>> Comment out the call to cleanup_vector?
>
> …
>
> Thanks for your help, these redrawing delays are really irritating.
You have long lost me on your discussion about Emacs internals, but I should just like to say that the unicode-fonts package from https://github.com/rolandwalker/unicode-fonts has fixed all these delays for me.
As far as I understand, this package maps Unicode blocks to specific fonts. I presume that Emacs would otherwise search through all installed fonts for one that supports the Unicode character that needs to be drawn, and that the explicit mapping prevents Emacs from doing that.
Seems that Eli was right with his “Fix your font configuration” remark.
Thanks for your help and your effort!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Fri, 12 Dec 2014 09:34:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 19266 <at> debbugs.gnu.org (full text, mbox):
On 12 December 2014 at 03:29, Sebastian Wiesner <swiesner <at> lunaryorn.com> wrote:
>
>> Am 12.12.2014 um 03:10 schrieb Kirill Ignatiev <kirill.ignatiev <at> gmail.com>:
>>
>> On 11 December 2014 at 12:45, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> Date: Wed, 10 Dec 2014 18:50:01 -0500
>>>> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
>>>> Cc: Sebastian Wiesner <swiesner <at> lunaryorn.com>, 19266 <at> debbugs.gnu.org
>>>
>>> Comment out the call to cleanup_vector?
>>
>> …
>>
>> Thanks for your help, these redrawing delays are really irritating.
>
> You have long lost me on your discussion about Emacs internals, but I should just like to say that the unicode-fonts package from https://github.com/rolandwalker/unicode-fonts has fixed all these delays for me.
I tried unicode-fonts now, and it does seem to fix the delays. Thanks!
But I still think there's a problem: my configuration, which led to
these delays, and my other example with one default font and one
special font for uncommon symbols, are both perfectly ordinary and
simple configurations. I'd say they shouldn't cause these kinds of
problems at all. In particular, unicode-fonts is not actually part of
emacs, so it's reasonable to expect emacs to work well enough without
it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Fri, 12 Dec 2014 10:58:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 19266 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 12 Dec 2014 04:33:06 -0500
> From: Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Antipov <dmantipov <at> yandex.ru>, 19266 <at> debbugs.gnu.org
>
> I tried unicode-fonts now, and it does seem to fix the delays. Thanks!
> But I still think there's a problem: my configuration, which led to
> these delays, and my other example with one default font and one
> special font for uncommon symbols, are both perfectly ordinary and
> simple configurations. I'd say they shouldn't cause these kinds of
> problems at all. In particular, unicode-fonts is not actually part of
> emacs, so it's reasonable to expect emacs to work well enough without
> it.
You are encouraged to continue investigating this problem and
reporting your findings here. It's quite possible that there's
something we need to fix, as the font releasing process was changed
lately, and could likely need improvements.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Wed, 17 Dec 2014 01:36:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 19266 <at> debbugs.gnu.org (full text, mbox):
On 12 December 2014 at 03:06, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Look up the call chain (best done by setting a breakpoint and looking
> at the backtrace), and you will certainly find a place which decides
> to discard them. Then comment out or change the code which does that.
>
> ...
>
> Again, look at the backtrace at a breakpoint in cleanup_vector and in
> compact_font_cache_entry. Isn't there some GC-related function on the
> callstack? Perhaps post that here, if you cannot figure that out.
The top function is garbage_collect, but whatever leads it to close
the fonts isn't triggered by a manual call to garbage-collect in
emacs.
Also: if the garbage collector isn't wrong, the fact that font
entities are garbage means that it really is okay to close them: they
wouldn't be accessible to all the other code anyway. I don't quite
understand how font_open_entity decides to load a font against using a
cache, but making sure fonts remain accessible to the call path
face_for_char -> fontset_font -> fontset_find_font -> font_open_entity
is probably the thing to do. Setting compact_font_cache_entry to a
noop doesn't seem to do the trick, font_open_entity gets called too
many times anyway, if I'm not mistaken.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Wed, 17 Dec 2014 02:14:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 19266 <at> debbugs.gnu.org (full text, mbox):
On some further testing, it seems that commenting out the section of
compact_font_caches that calls compact_font_cache_entry works (the
section surrounded in !defined(HAVE_NTGUI)). There are no more
repeated calls to font_open_entity, and fonts are not closed as
before. I am unable to reproduce the redisplay delay with the two-font
example above.
This presumably stops all cached fonts from being closed at all, ever,
so maybe there should be a more elegant solution. This could (?) be an
issue that mark_face_cache just doesn't mark enough fonts, so unused
fonts get discarded and must be loaded again. Also, this doesn't
explain why garbage-collect doesn't seem to trigger font closing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Sat, 30 Apr 2022 15:45:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 19266 <at> debbugs.gnu.org (full text, mbox):
Kirill Ignatiev <kirill.ignatiev <at> gmail.com> writes:
> Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> in languages like haskell, julia or c++), and (I think) especially with
> an ornate color theme, I experience delays of maybe about five seconds
> when switching between buffers. Running emacs under lldb show a stack
> trace below; I get a similar stack trace from running `emacs -Q` and
> typing `C-h h` (`view-hello-file`), which takes quite a while to display
> the hello file.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Do you still see these delays in recent Emacs/OS versions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 30 Apr 2022 15:45:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Mon, 02 May 2022 16:23:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 19266 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat 30 Apr 2022 at 16:44 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Kirill Ignatiev <kirill.ignatiev <at> gmail.com> writes:
>
> > Often when I'm editing a file with many uncommon unicode symbols (e.g.,
> > in languages like haskell, julia or c++), and (I think) especially with
> > an ornate color theme, I experience delays of maybe about five seconds
> > when switching between buffers. Running emacs under lldb show a stack
> > trace below; I get a similar stack trace from running `emacs -Q` and
> > typing `C-h h` (`view-hello-file`), which takes quite a while to display
> > the hello file.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> Do you still see these delays in recent Emacs/OS versions?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
>
No, I don’t. This was such a long time ago, but between improvements to
emacs itself and using the unicode-fonts package I haven’t had font issues
in ages now.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19266; Package
emacs.
(Tue, 03 May 2022 09:07:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 19266 <at> debbugs.gnu.org (full text, mbox):
Kirill Ignatiev <kirill.ignatiev <at> gmail.com> writes:
> No, I don’t. This was such a long time ago, but between improvements to emacs
> itself and using the unicode-fonts package I haven’t had font issues in ages now.
Thanks; I'm closing this bug report, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
19266 <at> debbugs.gnu.org and Kirill Ignatiev <kirill.ignatiev <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Tue, 03 May 2022 09:07:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 31 May 2022 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 46 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.