On Tue, 3 Sep 2024, at 13:52, Eli Zaretskii wrote: >> Date: Tue, 03 Sep 2024 12:27:09 +0100 >> From: "Stephane Travostino" <s...@combo.cc> >> 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" <s...@combo.cc> >> >>> >> >>> 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.