all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tom Seddon <emacs@tomseddon.plus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 6364@debbugs.gnu.org
Subject: bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW	fails.
Date: Tue, 26 Nov 2013 21:50:02 +0000	[thread overview]
Message-ID: <F57858CE-3ADA-44EB-8CF2-39EC0FD638CB@tomseddon.plus.com> (raw)
In-Reply-To: <83ioveanyq.fsf@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).

This function only works for bitmap fonts, but hopefully if GetGlyphOutlineW ever fails, the reason is that the font is a bitmap one! (And if not, and GetCharWidth32 fails too, there's the same fallback as before in the form of GetTextExtentPoint32.)

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

Thanks,

--Tom

P.S. my two PCs are as follows, and unpatched emacs performs poorly on both of them when using bitmap fonts:

- 3.4GHz Core i7 desktop, 16GB RAM, GeForce 560Ti, Windows 7
- 2.53GHz Core 2 Duo laptop, 8GB RAM, GeForce 9400M, Windows 7 (this is a Macbook Pro - the performance is also bad running in a VM)

So this could be something to do with NVidia display drivers on Windows 7, I suppose? Though I'd expect the VM to have its own drivers, suggesting that it might not actually be the graphics card vendor...

-----------------------------------

From 09fe3b0c0eb07c5ada87aee0864fa1d9478fdcf1 Mon Sep 17 00:00:00 2001
From: Tom Seddon <tom@tmbp-w7>
Date: Mon, 25 Nov 2013 22:19:47 +0000
Subject: [PATCH] Use GetCharWidth32W if GetGlyphOutlineW fails.

The previous fallback - which will still be used if GetCharWidth32W
fails - was to call GetTextExtentPoint32W. This can be rather slow,
mainly due to having to create a DC for it each time - but not to say
that using the cache isn't cheaper than GetTextExtentPoint32W anyway.
---
 src/w32font.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/src/w32font.c b/src/w32font.c
index 5c5a15c..08316ec 100644
--- a/src/w32font.c
+++ b/src/w32font.c
@@ -149,6 +149,7 @@ static BOOL g_b_init_get_outline_metrics_w;
 static BOOL g_b_init_get_text_metrics_w;
 static BOOL g_b_init_get_glyph_outline_w;
 static BOOL g_b_init_get_glyph_outline_w;
+static BOOL g_b_init_get_char_width_32_w;
 
 typedef UINT (WINAPI * GetOutlineTextMetricsW_Proc) (
    HDC hdc,
@@ -165,6 +166,11 @@ typedef DWORD (WINAPI * GetGlyphOutlineW_Proc) (
    DWORD cbBuffer,
    LPVOID lpvBuffer,
    const MAT2 *lpmat2);
+typedef BOOL (WINAPI * GetCharWidth32W_Proc) (
+   HDC hdc,
+   UINT uFirstChar,
+   UINT uLastChar,
+   LPINT lpBuffer);
 
 /* Several "wide" functions we use to support the font backends are
    unavailable on Windows 9X, unless UNICOWS.DLL is installed (their
@@ -274,6 +280,23 @@ get_glyph_outline_w (HDC hdc, UINT uChar, UINT uFormat, LPGLYPHMETRICS lpgm,
 				   lpvBuffer, lpmat2);
 }
 
+static DWORD WINAPI get_char_width_32_w (HDC hdc, UINT uFirstChar,
+					 UINT uLastChar, LPINT lpBuffer)
+{
+  static GetCharWidth32W_Proc s_pfn_Get_Char_Width_32W = NULL;
+  HMODULE hm_unicows = NULL;
+  if (g_b_init_get_char_width_32_w == 0)
+    {
+      g_b_init_get_char_width_32_w = 1;
+      hm_unicows = w32_load_unicows_or_gdi32 ();
+      if (hm_unicows)
+	s_pfn_Get_Char_Width_32W = (GetCharWidth32W_Proc)
+	  GetProcAddress (hm_unicows, "GetCharWidth32W");
+    }
+  eassert (s_pfn_Get_Char_Width_32W != NULL);
+  return s_pfn_Get_Char_Width_32W (hdc, uFirstChar, uLastChar, lpBuffer);
+}
+
 static int
 memq_no_quit (Lisp_Object elt, Lisp_Object list)
 {
@@ -2438,6 +2461,7 @@ compute_metrics (HDC dc, struct w32font_info *w32_font, unsigned int code,
   GLYPHMETRICS gm;
   MAT2 transform;
   unsigned int options = GGO_METRICS;
+  INT width;
 
   if (w32_font->glyph_idx)
     options |= GGO_GLYPH_INDEX;
@@ -2454,6 +2478,13 @@ compute_metrics (HDC dc, struct w32font_info *w32_font, unsigned int code,
       metrics->width = gm.gmCellIncX;
       metrics->status = W32METRIC_SUCCESS;
     }
+  else if (get_char_width_32_w (dc, code, code, &width) != 0)
+    {
+      metrics->lbearing = 0;
+      metrics->rbearing = width;
+      metrics->width = width;
+      metrics->status = W32METRIC_SUCCESS;
+    }
   else
     metrics->status = W32METRIC_FAIL;
 }
-- 
1.8.1.msysgit.1







  reply	other threads:[~2013-11-26 21:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-06 18:39 bug#6364: Windows: Emacs 23 slow with long lines and raster fonts bogossian
2013-11-26  0:35 ` bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW fails Tom Seddon
2013-11-26 17:52   ` Eli Zaretskii
2013-11-26 19:39     ` Tom Seddon
2013-11-26 20:20       ` Eli Zaretskii
2013-11-26 20:30         ` Tom Seddon
2013-11-26 20:48           ` Eli Zaretskii
2013-11-26 21:50             ` Tom Seddon [this message]
2013-11-26 21:53               ` Tom Seddon
2013-11-29 11:05               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F57858CE-3ADA-44EB-8CF2-39EC0FD638CB@tomseddon.plus.com \
    --to=emacs@tomseddon.plus.com \
    --cc=6364@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.