unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#39133: 28.0.50; Emacs slowdown on special char
@ 2020-01-14 13:21 Evgeny Zajcev
  2020-01-14 15:26 ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Evgeny Zajcev @ 2020-01-14 13:21 UTC (permalink / raw)
  To: 39133

[-- Attachment #1: Type: text/plain, Size: 11078 bytes --]

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%
     - next-line                                                    198  15%
      - line-move                                                   198  15%
       - line-move-1                                                198  15%
        + vertical-motion                                            94   7%
     + execute-extended-command                                       1   0%
    + byte-code                                                     101   8%
    auto-compose-chars                                              185  14%
  + timer-event-handler                                             175  14%
  - redisplay_internal (C function)                                  75   6%
     auto-compose-chars                                              75   6%
  - ...                                                              30   2%
     Automatic GC                                                    30   2%

As I remember I did not experienced something similar in Emacs 26/27

Thanks

--------------------
In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.18.9,
cairo version 1.14.6)
 of 2020-01-13 built on wrt
Repository revision: 7c5d6a2afc6c23a7fff8456f506ee2aa2d37a3b9
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.1 LTS

Recent messages:
next-line: End of buffer [2 times]
Mark activated [2 times]
CPU profiler stopped
CPU profiler started
Mark set
Quit
Mark set
CPU profiler stopped
CPU profiler started
Mark set

Configured using:
 'configure --with-modules --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: ru_RU.UTF-8
  value of $LC_NUMERIC: ru_RU.UTF-8
  value of $LC_TIME: ru_RU.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tracking-mode: t
  telega-mode-line-mode: t
  icomplete-mode: t
  save-place-mode: t
  pyvenv-mode: t
  shell-dirtrack-mode: t
  display-time-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  override-global-mode: t
  cl-old-struct-compat-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Load-path shadows:
/home/lg/.emacs.d/elpa/circe-20180105.1158/tracking hides
/home/lg/.emacs.d/elpa/tracking-20171210.2102/tracking
/home/lg/.emacs.d/elpa/circe-20180105.1158/shorten hides
/home/lg/.emacs.d/elpa/tracking-20171210.2102/shorten
~/dev/xelb/xcb-renderutil hides
/home/lg/.emacs.d/elpa/xelb-0.18/xcb-renderutil
~/dev/xelb/xcb-xinput hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xinput
~/dev/xelb/xcb-shape hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-shape
~/dev/xelb/xcb-icccm hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-icccm
~/dev/xelb/xcb-dri3 hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dri3
~/dev/xelb/xcb-xc_misc hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xc_misc
~/dev/xelb/xcb-render hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-render
~/dev/xelb/xcb-xf86vidmode hides
/home/lg/.emacs.d/elpa/xelb-0.18/xcb-xf86vidmode
~/dev/xelb/xcb-cursor hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-cursor
~/dev/xelb/xcb-dri2 hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dri2
~/dev/xelb/xcb-xprint hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xprint
~/dev/xelb/xcb-systemtray hides
/home/lg/.emacs.d/elpa/xelb-0.18/xcb-systemtray
~/dev/xelb/xcb-composite hides
/home/lg/.emacs.d/elpa/xelb-0.18/xcb-composite
~/dev/xelb/xcb-types hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-types
~/dev/xelb/xcb-dpms hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-dpms
~/dev/xelb/xcb-bigreq hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-bigreq
~/dev/xelb/xcb-xselinux hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xselinux
~/dev/xelb/xcb-xproto hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xproto
~/dev/xelb/xcb-xlib hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xlib
~/dev/xelb/xcb-xf86dri hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xf86dri
~/dev/xelb/xcb hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb
~/dev/xelb/xcb-xembed hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xembed
~/dev/xelb/xcb-present hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-present
~/dev/xelb/xcb-screensaver hides
/home/lg/.emacs.d/elpa/xelb-0.18/xcb-screensaver
~/dev/xelb/xcb-shm hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-shm
~/dev/xelb/xcb-ge hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-ge
~/dev/xelb/xcb-xinerama hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xinerama
~/dev/xelb/xcb-xim hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xim
~/dev/xelb/xcb-damage hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-damage
~/dev/xelb/xcb-glx hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-glx
~/dev/xelb/xcb-sync hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-sync
~/dev/xelb/xcb-res hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-res
~/dev/xelb/xcb-xfixes hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xfixes
~/dev/xelb/xcb-xtest hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xtest
~/dev/xelb/xcb-keysyms hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-keysyms
~/dev/xelb/xcb-ewmh hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-ewmh
~/dev/xelb/el_client hides /home/lg/.emacs.d/elpa/xelb-0.18/el_client
~/dev/xelb/xcb-record hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-record
~/dev/xelb/xcb-xv hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xv
~/dev/xelb/xcb-randr hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-randr
~/dev/xelb/xcb-xkb hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xkb
~/dev/xelb/xcb-xevie hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xevie
~/dev/xelb/xcb-xvmc hides /home/lg/.emacs.d/elpa/xelb-0.18/xcb-xvmc
~/dev/xelb/xelb hides /home/lg/.emacs.d/elpa/xelb-0.18/xelb

Features:
(shadow sort mail-extr emacsbug sendmail descr-text bug-reference
cc-mode cc-fonts cc-guess cc-menus cc-styles cc-align apropos profiler
find-func disp-table fill-column-indicator vc vc-dispatcher vc-git
smerge-mode git log-edit pcvs-util add-log misearch multi-isearch
wordfreq face-remap rect mm-archive gnutls network-stream url-cache
multitran mule-util hl-line tracking shorten telega telega-modes
telega-webpage telega-tme visual-fill-column telega-chat telega-i18n
telega-company telega-user telega-sticker telega-notifications
notifications dbus telega-msg telega-vvnote telega-media telega-root
telega-voip telega-ffplay telega-info telega-filter telega-ins
telega-inline telega-tdlib telega-util color svg dom xml ewoc
telega-server telega-core cursor-sensor telega-customize exwm-wconf
winner exwm-misc exwm exwm-match exwm-input xcb-keysyms exwm-manage
exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core
xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types work desktop frameset
gnus-demon nntp gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc gnus-spec gnus-win nnoo gnus-int gnus-range
message rfc822 mml mml-sec epa epg epg-config mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader gnus nnheader gnus-util rmail
rmail-loaddefs text-property-search mail-utils autoinsert cal-menu
calendar cal-loaddefs icomplete saveplace cython-mode company-capf
company pcase help-fns radix-tree elpy find-file-in-project ivy delsel
ivy-overlay ffap windmove diff-mode elpy-shell pyvenv elpy-profile
elpy-django elpy-refactor python tramp-sh tramp tramp-loaddefs trampver
tramp-integration tramp-compat parse-time iso8601 time-date ls-lisp
format-spec grep files-x etags fileloop generator xref project cus-edit
cus-start cus-load wid-edit python-mode info-look which-func imenu shell
pcomplete hippie-exp flymake-proc flymake warnings thingatpt compile
cc-cmds cc-engine cc-vars cc-defs dot-mode gist dired dired-loaddefs
gh-gist gh-oauth gh-api logito gh-cache pcache gh-auth gh-url url-http
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny timezone eieio-base server time
google-translate google-translate-default-ui google-translate-core-ui
google-translate-core google-translate-tk url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap whitespace undo-tree diff ido comint ansi-color ring avoid
ibuffer-vc ibuf-ext ibuffer ibuffer-loaddefs edmacro kmacro
browse-kill-ring derived cl cl-extra help-mode use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core tex-site
gh-common gh-profile rx s marshal eieio-compat dash advice info package
easymenu browse-url url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 844236 204685)
 (symbols 48 53129 1)
 (strings 32 212317 6977)
 (string-bytes 1 7670144)
 (vectors 16 104746)
 (vector-slots 8 3029493 25214)
 (floats 8 5990 341)
 (intervals 56 26458 1076)
 (buffers 1000 53)
 (heap 1024 91340 6613))

-- 
lg

[-- Attachment #2: Type: text/html, Size: 12412 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-14 13:21 bug#39133: 28.0.50; Emacs slowdown on special char Evgeny Zajcev
@ 2020-01-14 15:26 ` Eli Zaretskii
  2020-01-14 16:24   ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-01-14 15:26 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 39133

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

Does it help to set inhibit-compacting-font-caches non-nil?

> As I remember I did not experienced something similar in Emacs 26/27

I don't think Emacs < 27 supported variation selectors, did it?





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-14 15:26 ` Eli Zaretskii
@ 2020-01-14 16:24   ` Robert Pluim
  2020-01-15  4:26     ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-14 16:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Evgeny Zajcev, 39133

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-14 16:24   ` Robert Pluim
@ 2020-01-15  4:26     ` YAMAMOTO Mitsuharu
  2020-01-15  8:25       ` Robert Pluim
  2020-01-15 16:19       ` Eli Zaretskii
  0 siblings, 2 replies; 17+ messages in thread
From: YAMAMOTO Mitsuharu @ 2020-01-15  4:26 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Evgeny Zajcev, 39133

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





^ permalink raw reply related	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-15  4:26     ` YAMAMOTO Mitsuharu
@ 2020-01-15  8:25       ` Robert Pluim
  2020-01-15 10:47         ` Evgeny Zajcev
  2020-01-15 16:19       ` Eli Zaretskii
  1 sibling, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-15  8:25 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: Evgeny Zajcev, 39133

>>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

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

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

I donʼt know either, but your patch fixes the slowdown and Iʼve seen
no negative effects yet.

Robert





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-15  8:25       ` Robert Pluim
@ 2020-01-15 10:47         ` Evgeny Zajcev
  0 siblings, 0 replies; 17+ messages in thread
From: Evgeny Zajcev @ 2020-01-15 10:47 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 39133

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

ср, 15 янв. 2020 г. в 11:25, Robert Pluim <rpluim@gmail.com>:

> >>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <
> mituharu@math.s.chiba-u.ac.jp> said:
>
>     YAMAMOTO> 0xFFFFFFFF comes from FONT_INVALID_CODE.
> font->driver->text_extents
>     YAMAMOTO> shouldn't be called if font->font->driver->encode_char
> returns it.
>
>     YAMAMOTO> diff --git a/src/font.c b/src/font.c
>     YAMAMOTO> index 2b90903c90..03e6176220 100644
>     YAMAMOTO> --- a/src/font.c
>     YAMAMOTO> +++ b/src/font.c
>     YAMAMOTO> @@ -4420,15 +4420,19 @@ font_fill_lglyph_metrics
> (Lisp_Object glyph, Lisp_Object font_object)
>     YAMAMOTO>  {
>     YAMAMOTO>    struct font *font = XFONT_OBJECT (font_object);
>     YAMAMOTO>    unsigned code = font->driver->encode_char (font,
> LGLYPH_CHAR (glyph));
>     YAMAMOTO> -  struct font_metrics metrics;
>     YAMAMOTO> -
>     YAMAMOTO> -  LGLYPH_SET_CODE (glyph, code);
>     YAMAMOTO> -  font->driver->text_extents (font, &code, 1, &metrics);
>     YAMAMOTO> -  LGLYPH_SET_LBEARING (glyph, metrics.lbearing);
>     YAMAMOTO> -  LGLYPH_SET_RBEARING (glyph, metrics.rbearing);
>     YAMAMOTO> -  LGLYPH_SET_WIDTH (glyph, metrics.width);
>     YAMAMOTO> -  LGLYPH_SET_ASCENT (glyph, metrics.ascent);
>     YAMAMOTO> -  LGLYPH_SET_DESCENT (glyph, metrics.descent);
>     YAMAMOTO> +
>     YAMAMOTO> +  if (code != FONT_INVALID_CODE)
>     YAMAMOTO> +    {
>     YAMAMOTO> +      struct font_metrics metrics;
>     YAMAMOTO> +
>     YAMAMOTO> +      LGLYPH_SET_CODE (glyph, code);
>     YAMAMOTO> +      font->driver->text_extents (font, &code, 1, &metrics);
>     YAMAMOTO> +      LGLYPH_SET_LBEARING (glyph, metrics.lbearing);
>     YAMAMOTO> +      LGLYPH_SET_RBEARING (glyph, metrics.rbearing);
>     YAMAMOTO> +      LGLYPH_SET_WIDTH (glyph, metrics.width);
>     YAMAMOTO> +      LGLYPH_SET_ASCENT (glyph, metrics.ascent);
>     YAMAMOTO> +      LGLYPH_SET_DESCENT (glyph, metrics.descent);
>     YAMAMOTO> +    }
>     YAMAMOTO>  }
>
>
>     YAMAMOTO> But I'm not sure if it is ok to leave the code and
> metrics-related
>     YAMAMOTO> fields nil when encode_char returns FONT_INVALID_CODE.
> Handa-san?
>
> I donʼt know either, but your patch fixes the slowdown and Iʼve seen
> no negative effects yet.
>

Yeah, this patch fixes the slowdown!

-- 
lg

[-- Attachment #2: Type: text/html, Size: 3182 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-15  4:26     ` YAMAMOTO Mitsuharu
  2020-01-15  8:25       ` Robert Pluim
@ 2020-01-15 16:19       ` Eli Zaretskii
  2020-01-24 10:13         ` Robert Pluim
  1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-01-15 16:19 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: lg.zevlg, rpluim, 39133

> Date: Wed, 15 Jan 2020 13:26:11 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Eli Zaretskii <eliz@gnu.org>,
> 	Evgeny Zajcev <lg.zevlg@gmail.com>,
> 	39133@debbugs.gnu.org, handa@gnu.org
> 
> +  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?

We could do in the 'else' branch the same we do in the single caller
of this function, fill_gstring_body, when we don't call
font_fill_lglyph_metrics:

      if (FONT_OBJECT_P (font_object))
	{
	  font_fill_lglyph_metrics (g, font_object);
	}
      else
	{
	  int width = XFIXNAT (CHAR_TABLE_REF (Vchar_width_table, c));

	  LGLYPH_SET_CODE (g, c);
	  LGLYPH_SET_LBEARING (g, 0);
	  LGLYPH_SET_RBEARING (g, width);
	  LGLYPH_SET_WIDTH (g, width);
	  LGLYPH_SET_ASCENT (g, 1);
	  LGLYPH_SET_DESCENT (g, 0);
	}





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-15 16:19       ` Eli Zaretskii
@ 2020-01-24 10:13         ` Robert Pluim
  2020-01-24 10:22           ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-24 10:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39133, lg.zevlg

>>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said:
    Eli> We could do in the 'else' branch the same we do in the single caller
    Eli> of this function, fill_gstring_body, when we don't call
    Eli> font_fill_lglyph_metrics:

Rather than duplicate that code, I moved the FONT_INVALID_CODE check
up. This works for me:

diff --git a/src/composite.c b/src/composite.c
index 53e6930b5f..bf5884fa55 100644
--- a/src/composite.c
+++ b/src/composite.c
@@ -818,6 +818,7 @@ fill_gstring_body (Lisp_Object gstring)
   Lisp_Object header = AREF (gstring, 0);
   ptrdiff_t len = LGSTRING_CHAR_LEN (gstring);
   ptrdiff_t i;
+  struct font *font = XFONT_OBJECT (font_object);
 
   for (i = 0; i < len; i++)
     {
@@ -832,9 +833,12 @@ fill_gstring_body (Lisp_Object gstring)
       LGLYPH_SET_FROM (g, i);
       LGLYPH_SET_TO (g, i);
       LGLYPH_SET_CHAR (g, c);
-      if (FONT_OBJECT_P (font_object))
+
+      unsigned int code = font->driver->encode_char (font, LGLYPH_CHAR (g));
+
+      if (FONT_OBJECT_P (font_object) && code != FONT_INVALID_CODE)
 	{
-	  font_fill_lglyph_metrics (g, font_object);
+	  font_fill_lglyph_metrics (g, font_object, code);
 	}
       else
 	{
diff --git a/src/font.c b/src/font.c
index bb39aef92d..03d9cc50ae 100644
--- a/src/font.c
+++ b/src/font.c
@@ -4416,10 +4416,9 @@ DEFUN ("clear-font-cache", Fclear_font_cache, Sclear_font_cache, 0, 0, 0,
 
 \f
 void
-font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object)
+font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object, unsigned int code)
 {
   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);
diff --git a/src/font.h b/src/font.h
index 0561e3c83f..d82039eed8 100644
--- a/src/font.h
+++ b/src/font.h
@@ -886,7 +886,7 @@ valid_font_driver (struct font_driver const *d)
 extern Lisp_Object font_range (ptrdiff_t, ptrdiff_t, ptrdiff_t *,
 			       struct window *, struct face *,
 			       Lisp_Object);
-extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object);
+extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object, unsigned int);
 
 extern Lisp_Object font_put_extra (Lisp_Object font, Lisp_Object prop,
                                    Lisp_Object val);





^ permalink raw reply related	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 10:13         ` Robert Pluim
@ 2020-01-24 10:22           ` Eli Zaretskii
  2020-01-24 13:09             ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-01-24 10:22 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 39133, lg.zevlg

> From: Robert Pluim <rpluim@gmail.com>
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
>   39133@debbugs.gnu.org,  lg.zevlg@gmail.com,  handa@gnu.org
> Date: Fri, 24 Jan 2020 11:13:54 +0100
> 
> >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said:
>     Eli> We could do in the 'else' branch the same we do in the single caller
>     Eli> of this function, fill_gstring_body, when we don't call
>     Eli> font_fill_lglyph_metrics:
> 
> Rather than duplicate that code, I moved the FONT_INVALID_CODE check
> up. This works for me:

Looks reasonable, thanks.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 10:22           ` Eli Zaretskii
@ 2020-01-24 13:09             ` Robert Pluim
  2020-01-24 13:40               ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-24 13:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lg.zevlg, 39133

>>>>> On Fri, 24 Jan 2020 12:22:38 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
    >> 39133@debbugs.gnu.org,  lg.zevlg@gmail.com,  handa@gnu.org
    >> Date: Fri, 24 Jan 2020 11:13:54 +0100
    >> 
    >> >>>>> On Wed, 15 Jan 2020 18:19:28 +0200, Eli Zaretskii <eliz@gnu.org> said:
    Eli> We could do in the 'else' branch the same we do in the single caller
    Eli> of this function, fill_gstring_body, when we don't call
    Eli> font_fill_lglyph_metrics:
    >> 
    >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check
    >> up. This works for me:

    Eli> Looks reasonable, thanks.

Except it crashes under -nw. More investigation required.

Robert





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 13:09             ` Robert Pluim
@ 2020-01-24 13:40               ` Eli Zaretskii
  2020-01-24 13:50                 ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-01-24 13:40 UTC (permalink / raw)
  To: Robert Pluim; +Cc: lg.zevlg, 39133

> From: Robert Pluim <rpluim@gmail.com>
> Cc: lg.zevlg@gmail.com,  39133@debbugs.gnu.org,
>   mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
> Date: Fri, 24 Jan 2020 14:09:22 +0100
> 
>     >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check
>     >> up. This works for me:
> 
>     Eli> Looks reasonable, thanks.
> 
> Except it crashes under -nw.

Yes, because the call to the font driver should only be done when
'font_object' is a font object (it isn't on TTY frames).  Otherwise,
simply assign FONT_INVALID_CODE to 'code'.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 13:40               ` Eli Zaretskii
@ 2020-01-24 13:50                 ` Robert Pluim
  2020-01-24 15:41                   ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-24 13:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lg.zevlg, 39133

>>>>> On Fri, 24 Jan 2020 15:40:19 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: lg.zevlg@gmail.com,  39133@debbugs.gnu.org,
    >> mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
    >> Date: Fri, 24 Jan 2020 14:09:22 +0100
    >> 
    >> >> Rather than duplicate that code, I moved the FONT_INVALID_CODE check
    >> >> up. This works for me:
    >> 
    Eli> Looks reasonable, thanks.
    >> 
    >> Except it crashes under -nw.

    Eli> Yes, because the call to the font driver should only be done when
    Eli> 'font_object' is a font object (it isn't on TTY frames).  Otherwise,
    Eli> simply assign FONT_INVALID_CODE to 'code'.

Yes, I worked that out. A simple crash, for once :-)

Robert





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 13:50                 ` Robert Pluim
@ 2020-01-24 15:41                   ` Robert Pluim
  2020-01-24 15:52                     ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-01-24 15:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 39133, lg.zevlg

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

>>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said:
    Robert> Yes, I worked that out. A simple crash, for once :-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-attempt-to-cache-glyph-metrics-for-FONT_INVALI.patch --]
[-- Type: text/x-patch, Size: 3179 bytes --]

From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Fri, 24 Jan 2020 14:11:44 +0100
Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE

This was causing massive slowdown in redisplay when eg #xfe0f
(VARIATION SELECTOR-16) was present, as the cache ended up very large,
unused, and being recreated on every call to font_fill_lglyph_metrics
(Bug#39133).

* src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out
of loop.  Calculate glyph code and check for FONT_INVALID_CODE before
calling font_fill_lglyph_metrics.  Pass glyph code to it.

* src/font.c (font_fill_lglyph_metrics): Add code parameter, move
glyph code calculation up the call stack into fill_gstring_body.

* src/font.h: Adjust font_fill_lglyph_metrics prototype.
---
 src/composite.c | 18 ++++++++++++++----
 src/font.c      |  4 +---
 src/font.h      |  2 +-
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/src/composite.c b/src/composite.c
index 53e6930b5f..364d5c9316 100644
--- a/src/composite.c
+++ b/src/composite.c
@@ -818,6 +818,11 @@ fill_gstring_body (Lisp_Object gstring)
   Lisp_Object header = AREF (gstring, 0);
   ptrdiff_t len = LGSTRING_CHAR_LEN (gstring);
   ptrdiff_t i;
+  struct font *font = NULL;
+  unsigned int code;
+
+  if (FONT_OBJECT_P (font_object))
+    font = XFONT_OBJECT (font_object);
 
   for (i = 0; i < len; i++)
     {
@@ -832,10 +837,15 @@ fill_gstring_body (Lisp_Object gstring)
       LGLYPH_SET_FROM (g, i);
       LGLYPH_SET_TO (g, i);
       LGLYPH_SET_CHAR (g, c);
-      if (FONT_OBJECT_P (font_object))
-	{
-	  font_fill_lglyph_metrics (g, font_object);
-	}
+
+      if (font != NULL)
+        code = font->driver->encode_char (font, LGLYPH_CHAR (g));
+      else
+        code = FONT_INVALID_CODE;
+      if (code != FONT_INVALID_CODE)
+        {
+	  font_fill_lglyph_metrics (g, font, code);
+        }
       else
 	{
 	  int width = XFIXNAT (CHAR_TABLE_REF (Vchar_width_table, c));
diff --git a/src/font.c b/src/font.c
index bb39aef92d..2a45630061 100644
--- a/src/font.c
+++ b/src/font.c
@@ -4416,10 +4416,8 @@ DEFUN ("clear-font-cache", Fclear_font_cache, Sclear_font_cache, 0, 0, 0,
 
 \f
 void
-font_fill_lglyph_metrics (Lisp_Object glyph, Lisp_Object font_object)
+font_fill_lglyph_metrics (Lisp_Object glyph, struct font *font, unsigned int code)
 {
-  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);
diff --git a/src/font.h b/src/font.h
index 0561e3c83f..8614e7fa10 100644
--- a/src/font.h
+++ b/src/font.h
@@ -886,7 +886,7 @@ valid_font_driver (struct font_driver const *d)
 extern Lisp_Object font_range (ptrdiff_t, ptrdiff_t, ptrdiff_t *,
 			       struct window *, struct face *,
 			       Lisp_Object);
-extern void font_fill_lglyph_metrics (Lisp_Object, Lisp_Object);
+extern void font_fill_lglyph_metrics (Lisp_Object, struct font *, unsigned int);
 
 extern Lisp_Object font_put_extra (Lisp_Object font, Lisp_Object prop,
                                    Lisp_Object val);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 15:41                   ` Robert Pluim
@ 2020-01-24 15:52                     ` Eli Zaretskii
  2020-03-02  7:40                       ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-01-24 15:52 UTC (permalink / raw)
  To: Robert Pluim; +Cc: 39133, lg.zevlg

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 39133@debbugs.gnu.org,  lg.zevlg@gmail.com,
>   mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
> Date: Fri, 24 Jan 2020 16:41:40 +0100
> 
> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said:
>     Robert> Yes, I worked that out. A simple crash, for once :-)
> 
> >From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001
> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 24 Jan 2020 14:11:44 +0100
> Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE
> 
> This was causing massive slowdown in redisplay when eg #xfe0f
> (VARIATION SELECTOR-16) was present, as the cache ended up very large,
> unused, and being recreated on every call to font_fill_lglyph_metrics
> (Bug#39133).
> 
> * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out
> of loop.  Calculate glyph code and check for FONT_INVALID_CODE before
> calling font_fill_lglyph_metrics.  Pass glyph code to it.
> 
> * src/font.c (font_fill_lglyph_metrics): Add code parameter, move
> glyph code calculation up the call stack into fill_gstring_body.
> 
> * src/font.h: Adjust font_fill_lglyph_metrics prototype.

Thanks.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-01-24 15:52                     ` Eli Zaretskii
@ 2020-03-02  7:40                       ` Robert Pluim
  2020-03-02  8:49                         ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2020-03-02  7:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lg.zevlg, 39133

>>>>> On Fri, 24 Jan 2020 17:52:12 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 39133@debbugs.gnu.org,  lg.zevlg@gmail.com,
    >> mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
    >> Date: Fri, 24 Jan 2020 16:41:40 +0100
    >> 
    >> >>>>> On Fri, 24 Jan 2020 14:50:10 +0100, Robert Pluim <rpluim@gmail.com> said:
    Robert> Yes, I worked that out. A simple crash, for once :-)
    >> 
    >> >From 667f47abecc13e8a47181f338e727d95e57a6354 Mon Sep 17 00:00:00 2001
    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 24 Jan 2020 14:11:44 +0100
    >> Subject: [PATCH] Don't attempt to cache glyph metrics for FONT_INVALID_CODE
    >> 
    >> This was causing massive slowdown in redisplay when eg #xfe0f
    >> (VARIATION SELECTOR-16) was present, as the cache ended up very large,
    >> unused, and being recreated on every call to font_fill_lglyph_metrics
    >> (Bug#39133).
    >> 
    >> * src/composite.c (fill_gstring_body): Hoist FONT_OBJECT_P check out
    >> of loop.  Calculate glyph code and check for FONT_INVALID_CODE before
    >> calling font_fill_lglyph_metrics.  Pass glyph code to it.
    >> 
    >> * src/font.c (font_fill_lglyph_metrics): Add code parameter, move
    >> glyph code calculation up the call stack into fill_gstring_body.
    >> 
    >> * src/font.h: Adjust font_fill_lglyph_metrics prototype.

    Eli> Thanks.

So Mike Fabian has tested this, and it works for him. Which branch
would you like me to push this to?

Robert





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-03-02  7:40                       ` Robert Pluim
@ 2020-03-02  8:49                         ` Eli Zaretskii
  2020-03-02  9:25                           ` Robert Pluim
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2020-03-02  8:49 UTC (permalink / raw)
  To: Robert Pluim; +Cc: lg.zevlg, 39133

> From: Robert Pluim <rpluim@gmail.com>
> Cc: lg.zevlg@gmail.com,  39133@debbugs.gnu.org,
>   mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
> Date: Mon, 02 Mar 2020 08:40:02 +0100
> 
> So Mike Fabian has tested this, and it works for him. Which branch
> would you like me to push this to?

The release branch, please.

Thanks.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#39133: 28.0.50; Emacs slowdown on special char
  2020-03-02  8:49                         ` Eli Zaretskii
@ 2020-03-02  9:25                           ` Robert Pluim
  0 siblings, 0 replies; 17+ messages in thread
From: Robert Pluim @ 2020-03-02  9:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lg.zevlg, 39133-done

>>>>> On Mon, 02 Mar 2020 10:49:33 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: lg.zevlg@gmail.com,  39133@debbugs.gnu.org,
    >> mituharu@math.s.chiba-u.ac.jp,  handa@gnu.org
    >> Date: Mon, 02 Mar 2020 08:40:02 +0100
    >> 
    >> So Mike Fabian has tested this, and it works for him. Which branch
    >> would you like me to push this to?

    Eli> The release branch, please.

Done as fe1a447d52

Closing.

Robert









^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2020-03-02  9:25 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-14 13:21 bug#39133: 28.0.50; Emacs slowdown on special char Evgeny Zajcev
2020-01-14 15:26 ` Eli Zaretskii
2020-01-14 16:24   ` Robert Pluim
2020-01-15  4:26     ` YAMAMOTO Mitsuharu
2020-01-15  8:25       ` Robert Pluim
2020-01-15 10:47         ` Evgeny Zajcev
2020-01-15 16:19       ` Eli Zaretskii
2020-01-24 10:13         ` Robert Pluim
2020-01-24 10:22           ` Eli Zaretskii
2020-01-24 13:09             ` Robert Pluim
2020-01-24 13:40               ` Eli Zaretskii
2020-01-24 13:50                 ` Robert Pluim
2020-01-24 15:41                   ` Robert Pluim
2020-01-24 15:52                     ` Eli Zaretskii
2020-03-02  7:40                       ` Robert Pluim
2020-03-02  8:49                         ` Eli Zaretskii
2020-03-02  9:25                           ` Robert Pluim

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).