* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.