bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW fails.


From: Eli Zaretskii
Subject: bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW fails.
Date: Fri, 29 Nov 2013 13:05:54 +0200

> From: Tom Seddon <emacs@tomseddon.plus.com>
> Date: Tue, 26 Nov 2013 21:50:02 +0000
> Cc: 6364@debbugs.gnu.org
> 
> On 26 Nov 2013, at 20:48, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > OK.  So what other function(s) can be used for this purpose?
> > 
> > If there are no good alternatives, I guess we will go with
> > GetCharABCWidthsFloatW anyway, since the situation cannot become worse
> > than it is already.
> 
> I've changed it to GetCharWidth32, which is in the list on that MSDN page - 
> see patch below. I've checked this against all bitmap fonts on my system and 
> it produces the same results (and emacs looks to behave the same, including 
> in terms of performance).

Thanks, I committed this in your name, with one change: you forgot to
initialize g_b_init_get_char_width_32_w in globals_of_w32font.

> > Btw, I used your recipe, but didn't see any significant slowdown with
> > fixed.fon (also, the file bigline.txt is missing, I just used the
> > 16384 thingy instead.
> 
> Agh, my mistake - I should have included start-slow.el, not start-bigline.el. 
> Sorry. start-slow.el looks like this:
> 
> (set-face-attribute 'default nil :font "fixed")
> (switch-to-buffer (find-file "usb.ids"))
> (goto-char (point-max))
> 
> Maybe that will show up the problem? But it sounds rather like your computer 
> just doesn't suffer from this issue, for whatever reason...

I see the CPU usage decrease by half if I use Emacs with your patch
with a bitmap font, so I guess the effect is visible on my system as
well.

Thanks.  I'm closing this bug.





reply via email to

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