bug#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)

[Kenichi Handa <handa@m17n.org>]

In article <4A4201EF.7000901@gnu.org>, Jason Rumney <jasonr@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@m17n.org