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

[Eli Zaretskii <eliz@gnu.org>]

> 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.