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

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39133 <at> debbugs.gnu.org, Evgeny Zajcev <lg.zevlg <at> gmail.com>
Subject: Re: bug#39133: 28.0.50; Emacs slowdown on special char
Date: Tue, 14 Jan 2020 17:24:05 +0100

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

Previous Next

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