bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
Heavy operations, such as scrolling back and forth in a buffer, are noticeably laggier, for lack of better word, in the PGTK/Wayland version than the X11, both tested on KDE in Wayland mode. Affects both 29.2 and the latest HEAD compiled a few days ago. I am unsure whether it is a KDE or Emacs problem. Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x scaling. In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-08-29 built on toolbox.tranquility Repository revision: b6f4ffcc106fdbc21dfea45c75fdc4f217d8f201 Repository branch: makepkg Windowing system distributor 'The X.Org Foundation', version 11.0.12401002 System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --without-m17n-flt --without-gconf --with-native-compilation=yes --with-xinput2 --with-sound=no --with-tree-sitter --without-gpm --without-compress-install '--program-transform-name=s/\([ec]tags\)/\1.emacs/' 'CFLAGS=-march=native -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 LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: vertico-prescient-mode: t prescient-persist-mode: t marginalia-mode: t vertico-mode: t consult-notes-denote-mode: t denote-menu-bar-mode: t whole-line-or-region-global-mode: t whole-line-or-region-local-mode: t global-git-commit-mode: t magit-auto-revert-mode: t server-mode: t midnight-mode: t delete-selection-mode: t global-auto-revert-mode: t recentf-mode: t super-save-mode: t savehist-mode: t yas-global-mode: t yas-minor-mode: t direnv-mode: t pulsar-global-mode: t pulsar-mode: t which-key-mode: t winner-mode: t pixel-scroll-precision-mode: t override-global-mode: t gcmh-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tab-bar-mode: t file-name-shadow-mode: t context-menu-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t transient-mark-mode: (only . t) auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /var/home/sph/.emacs.d/elpa/ef-themes-1.6.1/theme-loaddefs hides /var/home/sph/.emacs.d/elpa/modus-themes-20240826.647/theme-loaddefs /var/home/sph/.emacs.d/elpa/which-key-20240620.2145/which-key hides /usr/share/emacs/31.0.50/lisp/which-key /var/home/sph/.emacs.d/elpa/transient-20240821.158/transient hides /usr/share/emacs/31.0.50/lisp/transient /var/home/sph/.emacs.d/elpa/ef-themes-1.6.1/theme-loaddefs hides /usr/share/emacs/31.0.50/lisp/theme-loaddefs /var/home/sph/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides /usr/share/emacs/31.0.50/lisp/bind-key /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package hides /usr/share/emacs/31.0.50/lisp/use-package/use-package /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-lint hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-lint /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-jump hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-jump /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-ensure hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-ensure /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-diminish hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-diminish /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-delight hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-delight /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-core hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-core /var/home/sph/.emacs.d/elpa/use-package-20230426.2324/use-package-bind-key hides /usr/share/emacs/31.0.50/lisp/use-package/use-package-bind-key /usr/share/emacs/site-lisp/xscheme hides /usr/share/emacs/31.0.50/lisp/progmodes/xscheme /var/home/sph/.emacs.d/elpa/idlwave-6.5.1/idlwave hides /usr/share/emacs/31.0.50/lisp/progmodes/idlwave /var/home/sph/.emacs.d/elpa/idlwave-6.5.1/idlw-toolbar hides /usr/share/emacs/31.0.50/lisp/progmodes/idlw-toolbar /var/home/sph/.emacs.d/elpa/idlwave-6.5.1/idlw-shell hides /usr/share/emacs/31.0.50/lisp/progmodes/idlw-shell /var/home/sph/.emacs.d/elpa/idlwave-6.5.1/idlw-help hides /usr/share/emacs/31.0.50/lisp/progmodes/idlw
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: >> Date: Mon, 02 Sep 2024 10:18:03 +0100 >> From: "Stephane Travostino" >> >> Heavy operations, such as scrolling back and forth in a buffer, are >> noticeably laggier, for lack of better word, in the PGTK/Wayland version >> than the X11, both tested on KDE in Wayland mode. >> >> Affects both 29.2 and the latest HEAD compiled a few days ago. >> >> I am unsure whether it is a KDE or Emacs problem. >> >> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x >> scaling. > > AFAIU, this is a problem with GTK input methods. From PROBLEMS: > > *** Emacs built with GTK lags in its response to keyboard input. > This can happen when input methods are used. It happens because Emacs > behaves in an unconventional way with respect to GTK input methods: it > registers to receive keyboard input as unprocessed key events with > metadata (as opposed to receiving them as text strings). Most GTK > programs use the latter approach, so some modern input methods have > bugs and misbehave when faced with the way Emacs does it. > > A workaround is to set GTK_IM_MODULE=none in the environment, or maybe > find a different input method without these problems. Thank you, though without more scientific methods of measuring latency I can't tell if that helps or not. I noticed I had pixel precision scrolling mode on and that contributed a large part to that feeling of lag compared to other programs. If Firefox is able to smooth scroll at 60 Hz, I would say empirically Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a choppy affair.
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
On Mon, 2 Sep 2024, at 13:12, Stephane Travostino wrote: > On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: >>> Date: Mon, 02 Sep 2024 10:18:03 +0100 >>> From: "Stephane Travostino" >>> >>> Heavy operations, such as scrolling back and forth in a buffer, are >>> noticeably laggier, for lack of better word, in the PGTK/Wayland version >>> than the X11, both tested on KDE in Wayland mode. >>> >>> Affects both 29.2 and the latest HEAD compiled a few days ago. >>> >>> I am unsure whether it is a KDE or Emacs problem. >>> >>> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x >>> scaling. >> >> AFAIU, this is a problem with GTK input methods. From PROBLEMS: >> >> *** Emacs built with GTK lags in its response to keyboard input. >> This can happen when input methods are used. It happens because Emacs >> behaves in an unconventional way with respect to GTK input methods: it >> registers to receive keyboard input as unprocessed key events with >> metadata (as opposed to receiving them as text strings). Most GTK >> programs use the latter approach, so some modern input methods have >> bugs and misbehave when faced with the way Emacs does it. >> >> A workaround is to set GTK_IM_MODULE=none in the environment, or maybe >> find a different input method without these problems. > > Thank you, though without more scientific methods of measuring latency > I can't tell if that helps or not. > > I noticed I had pixel precision scrolling mode on and that contributed > a large part to that feeling of lag compared to other programs. If > Firefox is able to smooth scroll at 60 Hz, I would say empirically > Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a > choppy affair. Update: GTK_IM_MODULE=none does not make it any less laggier. It is mostly felt in typing and editing source code, and switching to the X11 build makes it immensely snappier and doesn't feel like I'm working through a remote connection. FYI there are other reports online of people noticing major latency in HiDPI mode with the PGTK version, especially when the frame is fullscreen (so there's more pixels to update): https://old.reddit.com/r/emacs/comments/ucv0at/awful_performance_with_pgtk_on_wayland/ https://old.reddit.com/r/emacs/comments/1acdieh/pgtk_emacs_high_input_lag_at_large_frame_sizes_on/
bug#72960: 31.0.50; PGTK Wayland exhibits more lag than X11 version
On Tue, 3 Sep 2024, at 13:52, Eli Zaretskii wrote: >> Date: Tue, 03 Sep 2024 12:27:09 +0100 >> From: "Stephane Travostino" >> Cc: 72...@debbugs.gnu.org >> >> On Mon, 2 Sep 2024, at 13:12, Stephane Travostino wrote: >> > On Mon, 2 Sep 2024, at 13:05, Eli Zaretskii wrote: >> >>> Date: Mon, 02 Sep 2024 10:18:03 +0100 >> >>> From: "Stephane Travostino" >> >>> >> >>> Heavy operations, such as scrolling back and forth in a buffer, are >> >>> noticeably laggier, for lack of better word, in the PGTK/Wayland version >> >>> than the X11, both tested on KDE in Wayland mode. >> >>> >> >>> Affects both 29.2 and the latest HEAD compiled a few days ago. >> >>> >> >>> I am unsure whether it is a KDE or Emacs problem. >> >>> >> >>> Running on an AMD RX 6800 XT graphics card on a HiDPI 4k screen at 2x >> >>> scaling. >> >> >> >> AFAIU, this is a problem with GTK input methods. From PROBLEMS: >> >> >> >> *** Emacs built with GTK lags in its response to keyboard input. >> >> This can happen when input methods are used. It happens because Emacs >> >> behaves in an unconventional way with respect to GTK input methods: it >> >> registers to receive keyboard input as unprocessed key events with >> >> metadata (as opposed to receiving them as text strings). Most GTK >> >> programs use the latter approach, so some modern input methods have >> >> bugs and misbehave when faced with the way Emacs does it. >> >> >> >> A workaround is to set GTK_IM_MODULE=none in the environment, or maybe >> >> find a different input method without these problems. >> > >> > Thank you, though without more scientific methods of measuring latency >> > I can't tell if that helps or not. >> > >> > I noticed I had pixel precision scrolling mode on and that contributed >> > a large part to that feeling of lag compared to other programs. If >> > Firefox is able to smooth scroll at 60 Hz, I would say empirically >> > Emacs PGTK would scroll at 15 Hz, making navigation in the buffer a >> > choppy affair. >> >> Update: GTK_IM_MODULE=none does not make it any less laggier. It is mostly >> felt in typing and editing source code, and switching to the X11 build makes >> it immensely snappier and doesn't feel like I'm working through a remote >> connection. > > Please try profiling the lagging cases with "M-x profiler", and post > the profile here. I don't know how to make a consistent test case. I have tried here to profile opening Emacs (same commit with and without PGTK) on the same 547-line Elixir file, and holding the Down key until it reaches the bottom and then back to the top of the buffer. I have (setopt scroll-conservatively 101) so after the first page the contents are continuously redrawn for every new line. The PGTK version feels like it's skipping frames while it's relatively smooth on X11: X11: 8795 86% + redisplay_internal (C function) 1141 11% + command-execute 54 0% + direnv--maybe-update-environment 49 0% + gcmh-register-idle-gc 42 0% + winner-save-old-configurations 20 0% + timer-event-handler 18 0% + ... 18 0% + jit-lock--antiblink-post-command PGTK: 9387 91% + redisplay_internal (C function) 698 6% + command-execute 19 0% + ... 19 0% + timer-event-handler 12 0% + direnv--maybe-update-environment 11 0% + winner-save-old-configurations I have run this a few times and in Wayland `redisplay_internal` takes always a few percent more time than on X11, though I am not sure these numbers can prove anything as they are quite close. Is there some kind of consistent UI benchmark I can run? The frame skipping reminds me of missed vsync deadlines one might experience in games.
