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

Packages: w32, emacs;

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 3208 <at> debbugs.gnu.org, schierlm <at> gmx.de
Subject: 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)
Date: Wed, 24 Jun 2009 18:37:35 +0800
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.