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
View this message in rfc822 format
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.
Your change seems to have reduced the first time display of etc/HELLO
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.
This bug report was last modified 15 years and 307 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.