GNU bug report logs -
#40384
26.3; [Windows10] variable-pitch-mode is slow to redraw
Previous Next
Reported by: <gennady.uraltsev <at> gmail.com>
Date: Thu, 2 Apr 2020 00:07:02 UTC
Severity: normal
Tags: moreinfo
Found in version 26.3
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40384 in the body.
You can then email your comments to 40384 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Thu, 02 Apr 2020 00:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
<gennady.uraltsev <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 02 Apr 2020 00:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I am trying to emacs under Windows 10. variable-pitch-mode is insanely slow
in redrawing the screen. With a clean emacs.d I opened a text file and tried
pressing the down arrow. The cursor gets redisplayed every 10 lines or so
and emacs is very sluggish. It is interesting that this DOES NOT happen with
a normal, fixed-pitch, font and also does NOT happen if I set the default
font to be a variable pitch one e.g. "Segoe UI". It only happens with
variable-pitch-mode.
The same problem appears with all win32 versions of emacs that I found:
the cygwin emacs-32 package
$ uname -a
CYGWIN_NT-10.0 malevich 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
$ emacs-w32.exe --version
GNU Emacs 26.3
the official package:
$ emacs.exe --version
GNU Emacs 26.3
and with NTEmacs.
Also, interestingly enough, page by page movement with pg-down with
variable-pitch-mode seems ok and snappy. No fontification is active in my
attempts as I opened everything in fundamental mode.
Specifically, to reproduce start a clean emacs, dismiss the startup
screen and yank copies of the first two lines of the scratch buffer to
fill in your screen: 35 lines? Now execute: M-x variable-pitch-mode and
try moving around using arrow keys (up and down). The system slows down
and starts updating once every 0.5 -1 sec if you hold down/ input
movement keys consecutively. This does not happen on X11 builds.
If you change font, this problem still remains. Attached are
profiler results for moving down two pages worth of text.
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
Recent messages:
Buffer-Face mode enabled
funcall-interactively: End of buffer [3 times]
C-h C-g is undefined
Making completion list...
Type C-x 1 to delete the help window, C-M-v to scroll help.
previous-line: Beginning of buffer [65 times]
scroll-up-command: End of buffer
next-line: End of buffer [2 times]
Making completion list...
scroll-up-command: End of buffer
Configured using:
'configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2
Important settings:
value of $LANG: ENU
locale-coding-system: cp1251
Major mode: Lisp Interaction
Minor modes in effect:
buffer-face-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils pp wid-edit descr-text help-mode easymenu
cl-loaddefs cl-lib face-remap elec-pair time-date mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame 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 minibuffer
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 w32notify w32
lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 104193 13728)
(symbols 48 32234 1)
(miscs 40 63 381)
(strings 32 86233 1404)
(string-bytes 1 1941437)
(vectors 16 15512)
(vector-slots 8 899538 14224)
(floats 8 63 228)
(intervals 56 417 52)
(buffers 992 14))
[w32-variable-pitch-slow (application/octet-stream, attachment)]
[w32-normal (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Thu, 02 Apr 2020 14:42:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 40384 <at> debbugs.gnu.org (full text, mbox):
> From: <gennady.uraltsev <at> gmail.com>
> Date: Wed, 1 Apr 2020 20:06:38 -0400
>
> I am trying to emacs under Windows 10. variable-pitch-mode is insanely slow
> in redrawing the screen. With a clean emacs.d I opened a text file and tried
> pressing the down arrow. The cursor gets redisplayed every 10 lines or so
> and emacs is very sluggish. It is interesting that this DOES NOT happen with
> a normal, fixed-pitch, font and also does NOT happen if I set the default
> font to be a variable pitch one e.g. "Segoe UI". It only happens with
> variable-pitch-mode.
I don't think I can reproduce this.
Which font is used on your system when you turn on
variable-pitch-mode? (You can type "C-u C-x =" on a character to see
the font used to display it.)
> Attached are profiler results for moving down two pages worth of
> text.
Thanks, but you provided a "memory" profile, which is almost useless.
Please provide the "cpu" profile instead, and please show it in
human-readable form (after performing the measurement, type "M-x
profiler-report RET", then go to each top-level "+" sign and type "C-u
RET" to expand the profile; and finally paste the result into your
message and send it).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Thu, 02 Apr 2020 22:30:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 40384 <at> debbugs.gnu.org (full text, mbox):
By default the font that gets used is
display: by this font (glyph code)
uniscribe:-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1
(#x03)
as given by describe-char. On the other hand I can, before enabling the
mode, execute
(custom-set-faces
'(variable-pitch ((t (:height 120 :family "Segoe UI" :foundry "MS " :slant
normal :weight normal :width normal)))))
and this gives
display: by this font (glyph code)
uniscribe:-outline-Segoe UI-normal-normal-normal-sans-24-*-*-*-p-*-iso8859-1
(#x37)
But slowness happens in both cases.
Here are the profiler reports for CPU for scrolling about 2 pages worth of
text by pushing the down arrow:
******Normal*******
- command-execute 3 75%
- call-interactively 3 75%
- byte-code 3 75%
- read-extended-command 3 75%
- completing-read 3 75%
- completing-read-default 3 75%
read-from-minibuffer 2 50%
- ... 1 25%
Automatic GC 1 25%
******variable-pitch-mode*******
- command-execute 92 97%
- call-interactively 92 97%
- funcall-interactively 91 96%
- next-line 89 94%
- line-move 89 94%
- line-move-partial 59 62%
- default-line-height 36 38%
default-font-height 36 38%
- window-screen-lines 23 24%
- default-line-height 23 24%
default-font-height 23 24%
- default-line-height 30 31%
default-font-height 30 31%
- execute-extended-command 2 2%
- sit-for 2 2%
redisplay 2 2%
- byte-code 1 1%
- read-extended-command 1 1%
- completing-read 1 1%
- completing-read-default 1 1%
- read-from-minibuffer 1 1%
- redisplay_internal (C function) 1 1%
- tool-bar-make-keymap 1 1%
- tool-bar-make-keymap-1 1 1%
- mapcar 1 1%
- #<compiled 0x1000d70c9> 1 1%
- eval 1 1%
- find-image 1 1%
image-search-load-path 1 1%
- ... 2 2%
Automatic GC 2 2%
Thanks!
-----Original Message-----
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Thursday, 2 April, 2020 10:41
To: gennady.uraltsev <at> gmail.com
Cc: 40384 <at> debbugs.gnu.org
Subject: Re: bug#40384: 26.3; [Windows10] variable-pitch-mode is slow to
redraw
> From: <gennady.uraltsev <at> gmail.com>
> Date: Wed, 1 Apr 2020 20:06:38 -0400
>
> I am trying to emacs under Windows 10. variable-pitch-mode is insanely
> slow in redrawing the screen. With a clean emacs.d I opened a text
> file and tried pressing the down arrow. The cursor gets redisplayed
> every 10 lines or so and emacs is very sluggish. It is interesting
> that this DOES NOT happen with a normal, fixed-pitch, font and also
> does NOT happen if I set the default font to be a variable pitch one
> e.g. "Segoe UI". It only happens with variable-pitch-mode.
I don't think I can reproduce this.
Which font is used on your system when you turn on variable-pitch-mode?
(You can type "C-u C-x =" on a character to see the font used to display
it.)
> Attached are profiler results for moving down two pages worth of text.
Thanks, but you provided a "memory" profile, which is almost useless.
Please provide the "cpu" profile instead, and please show it in
human-readable form (after performing the measurement, type "M-x
profiler-report RET", then go to each top-level "+" sign and type "C-u RET"
to expand the profile; and finally paste the result into your message and
send it).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Fri, 03 Apr 2020 07:05:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 40384 <at> debbugs.gnu.org (full text, mbox):
> From: <gennady.uraltsev <at> gmail.com>
> Cc: <40384 <at> debbugs.gnu.org>
> Date: Thu, 2 Apr 2020 18:29:07 -0400
>
> By default the font that gets used is
>
> display: by this font (glyph code)
>
> uniscribe:-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1
> (#x03)
That's the same font I get, but I see no slowdown.
Thanks for the profile, it says that somehow redrawing even ASCII
characters (if you indeed did that with the comment in *scratch*
copied many times, as your recipe says) is somehow very expensive on
your system.
Does it help to customize inhibit-compacting-font-caches to non-nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Wed, 08 Apr 2020 15:31:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 40384 <at> debbugs.gnu.org (full text, mbox):
Hello,
None of the suggested fixes have any impact. I just did a clean reinstall of
my OS (Windows 10 Enterprise 10.0.18363 Build 18363) and the issue is
present still. Should we try to investigate the issue?
I have another PC on which I am going to be reinstalling windows soon. I
will check there and report back. (To see if it is hardware or software
related or a combination of the two...)
Best,
Gennady
On April 3, 2020 03:04:19 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: <gennady.uraltsev <at> gmail.com>
>> Cc: <40384 <at> debbugs.gnu.org>
>> Date: Thu, 2 Apr 2020 18:29:07 -0400
>>
>> By default the font that gets used is
>>
>> display: by this font (glyph code)
>>
>> uniscribe:-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1
>> (#x03)
>
> That's the same font I get, but I see no slowdown.
>
> Thanks for the profile, it says that somehow redrawing even ASCII
> characters (if you indeed did that with the comment in *scratch*
> copied many times, as your recipe says) is somehow very expensive on
> your system.
>
> Does it help to customize inhibit-compacting-font-caches to non-nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Wed, 08 Apr 2020 15:39:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 40384 <at> debbugs.gnu.org (full text, mbox):
> From: "Gennady Uraltsev" <gennady.uraltsev <at> gmail.com>
> Date: Wed, 8 Apr 2020 11:30:22 -0400
> Cc: 40384 <at> debbugs.gnu.org
>
> None of the suggested fixes have any impact. I just did a clean reinstall of
> my OS (Windows 10 Enterprise 10.0.18363 Build 18363) and the issue is
> present still. Should we try to investigate the issue?
We probably should investigate, yes, but I don't know what else to
suggest. Ideas welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Sun, 05 Dec 2021 01:17:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 40384 <at> debbugs.gnu.org (full text, mbox):
"Gennady Uraltsev" <gennady.uraltsev <at> gmail.com> writes:
> None of the suggested fixes have any impact. I just did a clean reinstall of
> my OS (Windows 10 Enterprise 10.0.18363 Build 18363) and the issue is
> present still. Should we try to investigate the issue? I have another
> PC on which I am going to be reinstalling windows soon. I
> will check there and report back. (To see if it is hardware or software
> related or a combination of the two...)
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I don't see this slowdown with variable pitch fonts on Windows, either
(using Windows 11 and Emacs 28). Are you still seeing this issue (with
Emacs 27.2, for instance?)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 05 Dec 2021 01:17:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40384; Package
emacs.
(Fri, 21 Jan 2022 13:39:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 40384 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I don't see this slowdown with variable pitch fonts on Windows, either
> (using Windows 11 and Emacs 28). Are you still seeing this issue (with
> Emacs 27.2, for instance?)
More information was requested, but no response was given within a
month, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
40384 <at> debbugs.gnu.org and <gennady.uraltsev <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 21 Jan 2022 13:39:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 19 Feb 2022 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.