bug#39133: 28.0.50; Emacs slowdown on special char

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Evgeny Zajcev
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
Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Eli Zaretskii
> From: Evgeny Zajcev <[hidden email]>
> 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?



Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Robert Pluim
>>>>> On Tue, 14 Jan 2020 17:26:45 +0200, Eli Zaretskii <[hidden email]> said:

    >> From: Evgeny Zajcev <[hidden email]>
    >> 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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> said:
>
>     >> From: Evgeny Zajcev <[hidden email]>
>     >> 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
                                [hidden email]



Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Robert Pluim
In reply to this post by Evgeny Zajcev
>>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Evgeny Zajcev


ср, 15 янв. 2020 г. в 11:25, Robert Pluim <[hidden email]>:
>>>>> On Wed, 15 Jan 2020 13:26:11 +0900, YAMAMOTO Mitsuharu <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

bug#39133: 28.0.50; Emacs slowdown on special char

Eli Zaretskii
In reply to this post by YAMAMOTO Mitsuharu
> Date: Wed, 15 Jan 2020 13:26:11 +0900
> From: YAMAMOTO Mitsuharu <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>,
> Evgeny Zajcev <[hidden email]>,
> [hidden email], [hidden email]
>
> +  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);
        }