bug#39133: 28.0.50; Emacs slowdown on special char

[YAMAMOTO Mitsuharu]

On Wed, 15 Jan 2020 01:24:05 +0900,
Robert Pluim wrote:
> 
> >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Evgeny Zajcev <lg.zevlg@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@math.s.chiba-u.ac.jp