[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19266: 24.4; Font-related window redrawing delays on OS X

From: Kirill Ignatiev
Subject: bug#19266: 24.4; Font-related window redrawing delays on OS X
Date: Wed, 10 Dec 2014 18:50:01 -0500

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

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:

 t '(#x1d400 . #x1d7ff)
 (font-xlfd-name (find-font (font-spec :family "Symbola"))))

  (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)

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

Attachment: bugreport2_patch.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]