[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39133: 28.0.50; Emacs slowdown on special char
From: |
Robert Pluim |
Subject: |
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@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
- bug#39133: 28.0.50; Emacs slowdown on special char, Evgeny Zajcev, 2020/01/14
- bug#39133: 28.0.50; Emacs slowdown on special char, Eli Zaretskii, 2020/01/14
- bug#39133: 28.0.50; Emacs slowdown on special char,
Robert Pluim <=
- bug#39133: 28.0.50; Emacs slowdown on special char, Eli Zaretskii, 2020/01/15
- bug#39133: 28.0.50; Emacs slowdown on special char, Robert Pluim, 2020/01/24
- bug#39133: 28.0.50; Emacs slowdown on special char, Eli Zaretskii, 2020/01/24
- bug#39133: 28.0.50; Emacs slowdown on special char, Robert Pluim, 2020/01/24
- bug#39133: 28.0.50; Emacs slowdown on special char, Eli Zaretskii, 2020/01/24
- bug#39133: 28.0.50; Emacs slowdown on special char, Robert Pluim, 2020/01/24
- bug#39133: 28.0.50; Emacs slowdown on special char, Robert Pluim, 2020/01/24