From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#39133: 28.0.50; Emacs slowdown on special char Date: Wed, 15 Jan 2020 13:26:11 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <83lfqa5aa2.fsf@gnu.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="211557"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Cc: Evgeny Zajcev , 39133@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 15 05:27:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iraGv-000sTq-CJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jan 2020 05:27:13 +0100 Original-Received: from localhost ([::1]:49120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iraGt-0002Rb-P9 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Jan 2020 23:27:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46656) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iraGl-0002RQ-Oe for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2020 23:27:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iraGk-00054C-Dd for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2020 23:27:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56312) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iraGk-000545-AU for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2020 23:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iraGk-0000Ut-6r for bug-gnu-emacs@gnu.org; Tue, 14 Jan 2020 23:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Jan 2020 04:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39133 X-GNU-PR-Package: emacs Original-Received: via spool by 39133-submit@debbugs.gnu.org id=B39133.15790623771843 (code B ref 39133); Wed, 15 Jan 2020 04:27:02 +0000 Original-Received: (at 39133) by debbugs.gnu.org; 15 Jan 2020 04:26:17 +0000 Original-Received: from localhost ([127.0.0.1]:34052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iraG0-0000Tf-Ts for submit@debbugs.gnu.org; Tue, 14 Jan 2020 23:26:17 -0500 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:55993) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iraFy-0000TS-N3 for 39133@debbugs.gnu.org; Tue, 14 Jan 2020 23:26:15 -0500 Original-Received: from mathent.math.s.chiba-u.ac.jp (mathent [192.168.32.5]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 4E961F08ED; Wed, 15 Jan 2020 13:26:11 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174599 Archived-At: On Wed, 15 Jan 2020 01:24:05 +0900, Robert Pluim wrote: >=20 > >>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii sa= id: >=20 > >> From: Evgeny Zajcev > >> Date: Tue, 14 Jan 2020 16:21:23 +0300 > >>=20 > >> I'm experiencing extreme Emacs slowdown when VARIATION SELECTOR-16= char > >> is used somewhere in Emacs buffer. For example, I just executed: > >>=20 > >> (insert "a\xfe0f") > >>=20 > >> in *scratch* buffer. Moving cursor (when this char is visible) be= come > >> unbearable. Here is the results of cpu profiling: > >>=20 > >> - command-execute = 776 62% > >> - call-interactively 7= 76 62% > >> - funcall-interactively 67= 5 54% > >> - previous-line 476= 38% > >> - line-move 476 = 38% > >> - line-move-1 476 = 38% > >> + vertical-motion 225 1= 8% >=20 > Eli> Does it help to set inhibit-compacting-font-caches non-nil? >=20 > >> As I remember I did not experienced something similar in Emacs 26/= 27 >=20 > Eli> I don't think Emacs < 27 supported variation selectors, did it? >=20 > It=CA=BCs coming from the caching in ftcrfont_glyph_extents: >=20 > row =3D glyph / METRICS_NCOLS_PER_ROW; <=3D=3D glyph =3D=3D 0xFFFFFFFF,= row -> 0x1FFFFFF > col =3D glyph % METRICS_NCOLS_PER_ROW; > if (row >=3D ftcrfont_info->metrics_nrows) > { > ftcrfont_info->metrics =3D > 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 =3D row + 1; <=3D=3D=3D we=CA=BCre upd= ating > metrics_nrows, lets look in ftfont.h > } >=20 > ftfont.h: >=20 > #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. >=20 > Of course, I don=CA=BCt think glyph should be 0xFFFFFFFF, but that=CA=BCs= a > different problem. >=20 > 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_O= bject font_object) { struct font *font =3D XFONT_OBJECT (font_object); unsigned code =3D 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 !=3D 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); + } } =20 =20 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