GNU bug report logs - #59134
29.0.50; Pixel scroll precision mode is very CPU intensive and governor sensitive

Previous Next

Package: emacs;

Reported by: Luke Fernandes <luke124273 <at> googlemail.com>

Date: Tue, 8 Nov 2022 22:04:02 UTC

Severity: normal

Found in version 29.0.50

To reply to this bug, email your comments to 59134 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#59134; Package emacs. (Tue, 08 Nov 2022 22:04:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luke Fernandes <luke124273 <at> googlemail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 08 Nov 2022 22:04:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Luke Fernandes <luke124273 <at> googlemail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Pixel scroll precision mode is very CPU intensive and
 governor sensitive
Date: Tue, 8 Nov 2022 20:53:29 +0000
[Message part 1 (text/plain, inline)]
Not so much a bug as a request for an improvement/feature request.

When using pixel-scroll-precision-mode in Emacs, scrolling will be laggy or
choppy when the Linux kernel cpu governor is set to more power saving
modes, seemingly because clocks are less responsive to load and do not
rise from their idle state (on my Intel hexacore mobile Xeon, this is
800 Mhz) until a few seconds into the scroll, if at all. When the
governor is set to performance, clocks will go from mid-table to max/base
clock (I have
turbo boost disabled) instantly and stay there for the duration of the
scroll - and the scroll is buttery smooth.

On chrome or firefox, scrolling will in contrast be completely smooth even
if CPU
clocks remain at 800 MHz (say, under the most restrictive governor
policies or a maximum clock limit) for the entire scroll.

It is undesirable that a power balancing governor setting, which works
well for most or all other applications, should cause lag and stuttering
in smooth pixel scrolling in Emacs. I realise there are performance
constraints within Emacs' design, but if there's any way we can get
smooth scrolling to be more workable at lower clocks that would be great.


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.17.6) of 2022-09-26 built on Putty4-7manjaro
Repository revision: 93b9cf41846b40cd050b56f6e83b590330be255e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Manjaro Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-libotf --without-m17n-flt --without-gconf
 --with-native-compilation --with-xinput2 --with-x-toolkit=gtk3
 --without-xaw3d --with-sound=no --without-gpm
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB

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

Major mode: C++//l

Minor modes in effect:
  lsp-diagnostics-mode: t
  company-mode: t
  lsp-headerline-breadcrumb-mode: t
  lsp-modeline-workspace-status-mode: t
  lsp-modeline-diagnostics-mode: t
  lsp-modeline-code-actions-mode: t
  lsp-ui-mode: t
  lsp-ui-doc-mode: t
  lsp-ui-sideline-mode: t
  flycheck-mode: t
  lsp-completion-mode: t
  gcmh-mode: t
  pixel-scroll-precision-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  lsp-managed-mode: t
  lsp-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t

Load-path shadows:
/home/luke/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode

Features:
(shadow sort mail-extr emacsbug message yank-media dired dired-loaddefs
rfc822 mml mml-sec epa gnus-util mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader sendmail mail-utils novice help-fns
radix-tree cl-print debug backtrace lsp-diagnostics company-oddmuse
company-keywords company-etags etags fileloop company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company lsp-headerline lsp-icons lsp-modeline vc-git
diff-mode vc-dispatcher lsp-ui lsp-ui-flycheck derived lsp-ui-doc
goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline easy-mmode flycheck
lsp-ui-util face-remap view lsp-zig lsp-steep lsp-svelte lsp-sqls
lsp-yaml lsp-xml lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog
lsp-vala lsp-v lsp-toml lsp-terraform lsp-tex lsp-sorbet lsp-solargraph
lsp-rust lsp-rf lsp-r lsp-purescript lsp-pylsp lsp-pyls lsp-pwsh lsp-php
lsp-perl lsp-ocaml lsp-nix lsp-nim lsp-nginx lsp-markdown lsp-lua
lsp-kotlin lsp-json lsp-javascript lsp-haxe lsp-groovy lsp-hack
lsp-graphql lsp-go lsp-completion lsp-gdscript lsp-fsharp lsp-fortran
lsp-eslint lsp-erlang lsp-elixir lsp-elm lsp-dockerfile lsp-dhall lsp-d
lsp-css lsp-csharp gnutls lsp-crystal lsp-cmake lsp-clojure
lsp-semantic-tokens lsp-clangd dom lsp-beancount lsp-bash lsp-angular
lsp-ada lsp-actionscript gcmh pixel-scroll cua-base finder-inf ido
undo-tree diff ccls ccls-member-hierarchy ccls-inheritance-hierarchy
ccls-call-hierarchy ccls-tree ccls-code-lens ccls-semantic-highlight
ccls-common lsp-mode comp comp-cstr warnings lsp-protocol yasnippet xref
project tree-widget wid-edit spinner pcase network-stream markdown-mode
color thingatpt inline imenu ht filenotify f s ewoc epg rfc6068
epg-config dash compile text-property-search cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs org2blog
edmacro kmacro ox-wp ox-odt rng-loc rng-uri rng-parse rng-match rng-dt
rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar org-agenda org-refile ox-html table ox-ascii ox-publish ox
org-element avl-tree generator org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-footnote org-src ob-comint org-pcomplete pcomplete
comint osc ansi-color org-list org-faces org-entities noutline outline
icons org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic
bibtex iso8601 time-date ol rx org-keys oc org-compat org-macs
org-loaddefs format-spec advice find-func cal-menu calendar cal-loaddefs
writegood-mode metaweblog xml-rpc timezone url-http url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny
xml hydra ring lv htmlize cl-extra help-mode use-package-ensure
use-package-core delsel desktop frameset gcmh-autoloads
org2blog-autoloads metaweblog-autoloads hydra-autoloads
htmlize-autoloads slime-autoloads info writegood-mode-autoloads
xml-rpc-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv
bytecomp byte-compile cconv url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode 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 lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine 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 emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 656156 214917)
 (symbols 48 42926 0)
 (strings 32 201592 13610)
 (string-bytes 1 5716277)
 (vectors 16 81611)
 (vector-slots 8 1449007 230376)
 (floats 8 516 1897)
 (intervals 56 6899 1947)
 (buffers 1000 19))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#59134; Package emacs. (Wed, 09 Nov 2022 00:44:02 GMT) Full text and rfc822 format available.

Message #8 received at 59134 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Luke Fernandes <luke124273 <at> googlemail.com>
Cc: 59134 <at> debbugs.gnu.org
Subject: Re: bug#59134: 29.0.50; Pixel scroll precision mode is very CPU
 intensive and governor sensitive
Date: Wed, 09 Nov 2022 08:42:48 +0800
Luke Fernandes <luke124273 <at> googlemail.com> writes:

> Not so much a bug as a request for an improvement/feature request.
>
> When using pixel-scroll-precision-mode in Emacs, scrolling will be laggy or
> choppy when the Linux kernel cpu governor is set to more power saving
> modes, seemingly because clocks are less responsive to load and do not
> rise from their idle state (on my Intel hexacore mobile Xeon, this is
> 800 Mhz) until a few seconds into the scroll, if at all. When the
> governor is set to performance, clocks will go from mid-table to max/base clock (I have
> turbo boost disabled) instantly and stay there for the duration of the
> scroll - and the scroll is buttery smooth.
>
> On chrome or firefox, scrolling will in contrast be completely smooth even if CPU
> clocks remain at 800 MHz (say, under the most restrictive governor
> policies or a maximum clock limit) for the entire scroll.
>
> It is undesirable that a power balancing governor setting, which works
> well for most or all other applications, should cause lag and stuttering
> in smooth pixel scrolling in Emacs. I realise there are performance
> constraints within Emacs' design, but if there's any way we can get
> smooth scrolling to be more workable at lower clocks that would be great.
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.34, cairo version 1.17.6) of 2022-09-26 built on Putty4-7manjaro
> Repository revision: 93b9cf41846b40cd050b56f6e83b590330be255e
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Manjaro Linux

I know of this problem and will try to fix it.  But unfortunately it
isn't very high on my priority list, so it will probably not be fixed
until next year.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#59134; Package emacs. (Sun, 16 Jul 2023 14:11:02 GMT) Full text and rfc822 format available.

Message #11 received at 59134 <at> debbugs.gnu.org (full text, mbox):

From: Luke Fernandes <luke124273 <at> googlemail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 59134 <at> debbugs.gnu.org
Subject: Re: bug#59134: 29.0.50; Pixel scroll precision mode is very CPU
 intensive and governor sensitive
Date: Sun, 16 Jul 2023 13:48:45 +0100
[Message part 1 (text/plain, inline)]
Hi Po Lu, any progress on this? Currently it's hard to use this mode on a
laptop, since the governor setting needs to be changed to a high
performance one to get a smooth experience, leading to increased heat
dissipation and noise. Thanks.

On Wed, Nov 9, 2022 at 12:42 AM Po Lu <luangruo <at> yahoo.com> wrote:

> Luke Fernandes <luke124273 <at> googlemail.com> writes:
>
> > Not so much a bug as a request for an improvement/feature request.
> >
> > When using pixel-scroll-precision-mode in Emacs, scrolling will be laggy
> or
> > choppy when the Linux kernel cpu governor is set to more power saving
> > modes, seemingly because clocks are less responsive to load and do not
> > rise from their idle state (on my Intel hexacore mobile Xeon, this is
> > 800 Mhz) until a few seconds into the scroll, if at all. When the
> > governor is set to performance, clocks will go from mid-table to
> max/base clock (I have
> > turbo boost disabled) instantly and stay there for the duration of the
> > scroll - and the scroll is buttery smooth.
> >
> > On chrome or firefox, scrolling will in contrast be completely smooth
> even if CPU
> > clocks remain at 800 MHz (say, under the most restrictive governor
> > policies or a maximum clock limit) for the entire scroll.
> >
> > It is undesirable that a power balancing governor setting, which works
> > well for most or all other applications, should cause lag and stuttering
> > in smooth pixel scrolling in Emacs. I realise there are performance
> > constraints within Emacs' design, but if there's any way we can get
> > smooth scrolling to be more workable at lower clocks that would be great.
> >
> > In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> >  3.24.34, cairo version 1.17.6) of 2022-09-26 built on Putty4-7manjaro
> > Repository revision: 93b9cf41846b40cd050b56f6e83b590330be255e
> > Repository branch: master
> > Windowing system distributor 'The X.Org Foundation', version
> 11.0.12101004
> > System Description: Manjaro Linux
>
> I know of this problem and will try to fix it.  But unfortunately it
> isn't very high on my priority list, so it will probably not be fixed
> until next year.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 1 year and 134 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.