GNU bug report logs -
#3208
23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32)
Previous Next
Reported by: Michael Schierl <schierlm <at> gmx.de>
Date: Mon, 4 May 2009 18:35:03 UTC
Severity: normal
Done: Jason Rumney <jasonr <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #79 received at 3208 <at> emacsbugs.donarmstrong.com (full text, mbox):
In article <4A4201EF.7000901 <at> gnu.org>, Jason Rumney <jasonr <at> gnu.org> writes:
> Kenichi Handa wrote:
> > Although I still can't reproduce the problem (except for the
> > very slowness redisplay), I noticed some inefficiency in
> > fontset_font. So, I've installed an improvement in the
> > TRUNK. As a result, in the case of inserting many #x2203,
> > the redisplay got faster.
> The memory full problem is still there. I am surprised you don't see it
> if you are seeing the slowness, since if things were working correctly,
> only the first character displayed should be slow while the fonts are
> searched, subsequent insertion of the same character should reuse the
> cached font.
Even if Emacs once finds a font for a specific character C,
it doesn't directly cache the font for C. Instead, the font
is recorded in a font-group that is shared with the other
characters (in a fontset). So, each time we display C, we
must find a font that can display C within the cached fonts.
Of course, this process is, I think, far faster than
font-listing and opening, it is not instant especially when
the target font is at the end of the font-group.
The recipe of the original report inserts a very long line.
In that case, when Emacs displays a character at the end of
line, Emacs tries to check fonts of all characters in the
line. This takes considerable amount of time (in my case 4
seconds before my patch and 2.5 seconds after the patch)
even if the font is cached.
> Your change seems to have reduced the first time display of etc/HELLO
Actually it should reduce the second time display of a
specific group of characters. But, as HELLO file contains
many different characters belonging to the same group,
display of some characters gets faster if a character of the
same group is already shown.
> from 12 seconds for the uniscribe backend to 10 seconds, vs 2 seconds
> for the gdi backend and Emacs 22 (though only uniscribe can display the
> complex scripts correctly). Subsequent redisplays are near
> instantaneous, so it still seems to be searching for fonts rather than
> displaying them that takes the time.
Anyway, it is not good to use HELLO file for comparing
because Emacs 23 knows more kinds of fonts can display a
specific character and thus tries more fonts. So, it takes
more time to conclude that you system doesn't have a font
for that specific character.
---
Kenichi Handa
handa <at> m17n.org
This bug report was last modified 15 years and 308 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.