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.
