GNU bug report logs - #39133
28.0.50; Emacs slowdown on special char

Previous Next

Full log

Message #14 received at 39133 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 39133 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Evgeny Zajcev <lg.zevlg <at> gmail.com>, handa <at> gnu.org
Subject: Re: bug#39133: 28.0.50; Emacs slowdown on special char
Date: Wed, 15 Jan 2020 13:26:11 +0900

On Wed, 15 Jan 2020 01:24:05 +0900,
Robert Pluim wrote:
> 
> >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
>     >> Date: Tue, 14 Jan 2020 16:21:23 +0300
>     >> 
>     >> I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16 char
>     >> is used somewhere in Emacs buffer.  For example, I just executed:
>     >> 
>     >> (insert "a\xfe0f")
>     >> 
>     >> in *scratch* buffer.  Moving cursor (when this char is visible) become
>     >> unbearable.  Here is the results of cpu profiling:
>     >> 
>     >> - command-execute                                                 776  62%
>     >> - call-interactively                                             776  62%
>     >> - funcall-interactively                                         675  54%
>     >> - previous-line                                                476  38%
>     >> - line-move                                                   476  38%
>     >> - line-move-1                                                476  38%
>     >> + vertical-motion                                           225  18%
> 
>     Eli> Does it help to set inhibit-compacting-font-caches non-nil?
> 
>     >> As I remember I did not experienced something similar in Emacs 26/27
> 
>     Eli> I don't think Emacs < 27 supported variation selectors, did it?
> 
> Itʼs coming from the caching in ftcrfont_glyph_extents:
> 
>   row = glyph / METRICS_NCOLS_PER_ROW; <== glyph == 0xFFFFFFFF, row -> 0x1FFFFFF
>   col = glyph % METRICS_NCOLS_PER_ROW;
>   if (row >= ftcrfont_info->metrics_nrows)
>     {
>       ftcrfont_info->metrics =
> 	xrealloc (ftcrfont_info->metrics,
> 		  sizeof (struct font_metrics *) * (row + 1));
>       memset (ftcrfont_info->metrics + ftcrfont_info->metrics_nrows, 0,
> 	      (sizeof (struct font_metrics *)
> 	       * (row + 1 - ftcrfont_info->metrics_nrows)));
>       ftcrfont_info->metrics_nrows = row + 1; <=== weʼre updating
>   metrics_nrows, lets look in ftfont.h
>     }
> 
> ftfont.h:
> 
> #ifdef USE_CAIRO
>   cairo_scaled_font_t *cr_scaled_font;
>   /* Scale factor from the bitmap strike metrics in 1/64 pixels, used
>      as the hb_position_t value in HarfBuzz, to those in (scaled)
>      pixels.  The value is 0 for scalable fonts.  */
>   double bitmap_position_unit;
>   /* Font metrics cache.  */
>   struct font_metrics **metrics;
>   short metrics_nrows;
>   ^^^^^ oops! Now we end up calling xrealloc every time we enter
>   ftctfont_glyph_extents for that glyph.
> 
> Of course, I donʼt think glyph should be 0xFFFFFFFF, but thatʼs a
> different problem.
> 
> Robert

0xFFFFFFFF comes from FONT_INVALID_CODE. font->driver->text_extents
shouldn't be called if font->font->driver->encode_char returns it.

diff --git a/src/font.c b/src/font.c
index 2b90903c90..03e6176220 100644
--- a/src/font.c
+++ b/src/font.c
@@ -4420,15 +4420,19 @@ font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object)
 {
   struct font *font = XFONT_OBJECT (font_object);
   unsigned code = font->driver->encode_char (font, LGLYPH_CHAR (glyph));
-  struct font_metrics metrics;
-
-  LGLYPH_SET_CODE (glyph, code);
-  font->driver->text_extents (font, &code, 1, &metrics);
-  LGLYPH_SET_LBEARING (glyph, metrics.lbearing);
-  LGLYPH_SET_RBEARING (glyph, metrics.rbearing);
-  LGLYPH_SET_WIDTH (glyph, metrics.width);
-  LGLYPH_SET_ASCENT (glyph, metrics.ascent);
-  LGLYPH_SET_DESCENT (glyph, metrics.descent);
+
+  if (code != FONT_INVALID_CODE)
+    {
+      struct font_metrics metrics;
+
+      LGLYPH_SET_CODE (glyph, code);
+      font->driver->text_extents (font, &code, 1, &metrics);
+      LGLYPH_SET_LBEARING (glyph, metrics.lbearing);
+      LGLYPH_SET_RBEARING (glyph, metrics.rbearing);
+      LGLYPH_SET_WIDTH (glyph, metrics.width);
+      LGLYPH_SET_ASCENT (glyph, metrics.ascent);
+      LGLYPH_SET_DESCENT (glyph, metrics.descent);
+    }
 }
 
 
But I'm not sure if it is ok to leave the code and metrics-related
fields nil when encode_char returns FONT_INVALID_CODE.  Handa-san?

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.