GNU bug report logs -
#46350
28.0.50; touchpad-scrolling-eats-lots-of-cpu-samples
Previous Next
To reply to this bug, email your comments to 46350 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 17:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Andrey Orst <andreyorst <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 06 Feb 2021 17:35: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)]
Hello. I'm experiencing major slowdown in Emacs -q fundamental mode
when setting `mouse-wheel-progressive-speed' to `nil'. Here are
reproduction steps:
1. Run emacs -q
2. Open some big file, in my case I've opened lisp-mode.el
3. Turn on fundamental-mode (optional)
4. Go to the end of the buffer.
5. Rapidly produce scroll up events from touchpad or mouse wheel
(although it is much harder to achieve with mouse) with significant
scroll amount. By significant scroll amount I mean continuous
scrolling event from touchpad, which can be achieved by swiping over
whole touchpad area very rapidly.
6. Observe that Emacs doesn't scroll almost at all and just waits until
scroll events will stop. Then it scrolls correct amount.
The delay I'm talking about is what bothers me.
First, there's no delay at all when scrolling with scrollbars
(provided by `scroll-bar-mode'). I can scroll with scrollbars as
rapidly as I want, and there is literally no lag whatsoever.
Second, when producing slow scrolling motion on touchpad or mouse
(e.g. one line at a time) scrolling is very responsive. But I'm
scrolling one line at a time very rarely so this is useless to me.
Third, this bug also reproduces with default value of
`mouse-wheel-progressive-speed', although it is a bit more difficult
to catch this as it requires enormously big buffer for lag to build
up, as scrolling increases in speed (seemingly) exponentially and can
reach top of the buffer before lag builds up significantly.
Last but not least, this also happens when scrolling down (to buffer
end) but the lag seems to be smaller, yet it still noticeable.
I've did some profiling during irresponsibility the amount of CPU
samples is enormous, but down the tree, called functions don't consume
much. Here's a fragment of report, and I've also attached profiler
exported report to the mail:
4400 88% - command-execute
4359 87% - funcall-interactively
3776 75% - mwheel-scroll
26 0% mouse-wheel--get-scroll-window
26 0% - run-with-timer
23 0% - run-at-time
4 0% timer-set-time
1 0% timer-set-function
1 0% timer-activate
23 0% - scroll-up
12 0% - eval
8 0% - if
1 0% display-graphic-p
1 0% mode-line-eol-desc
19 0% - scroll-down
9 0% - eval
7 0% - if
1 0% frame-parameter
1 0% unless
15 0% - error-message-string
11 0% - substitute-command-keys
7 0% - #<compiled -0x1fc708cc6b8a9a73>
4 0% - kill-buffer
2 0% - replace-buffer-in-windows
1 0% - unrecord-window-buffer
1 0% assq-delete-all
2 0% #<compiled -0xd2dd66c27d231f8>
1 0% message
288 5% - scroll-bar-toolkit-scroll
264 5% - sit-for
10 0% - redisplay_internal (C function)
2 0% - eval
1 0% mode-line-eol-desc
1 0% if
My wild guess is that touchpad sends much more input to Emacs, compared
to mouse, and that's why scrolling function has to work with much more
inputs and hence the struggle. I was under assumption that Emacs'
font-lock was the culprit here, as disabling it kinda helps, but then
I've managed to reproduce it without font locking and now I think that
there might be another issue. Everything I've tested happened on GCC
Emacs branch, but also happens (and actually a bit more noticeable in
27.1 and master branches).
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.13, cairo version 1.16.0)
of 2021-01-17 built on toolbox
Repository revision: 88100bed0af530f04cf56acca9f9d1bb12b45771
Repository branch: feature/native-comp
Windowing system distributor 'Fedora Project', version 11.0.12010000
System Description: Fedora 33 (Workstation Edition)
Configured using:
'configure --with-nativecomp --with-mailutils
--prefix=/home/andreyorst/.local/emacs
--bindir=/home/andreyorst/.local/bin
'--program-transform-name=s/^ctags$/ctags.emacs/''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE
XIM XPM GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
global-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 dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils jka-compr shortdoc text-property-search
cl-indent comp comp-cstr warnings rx cl-seq cl-macs cl-extra seq
byte-opt gv bytecomp byte-compile cconv inf-lisp comint ansi-color ring
thingatpt profiler help-fns radix-tree cl-print debug backtrace
help-mode find-func time-date subr-x vc-git diff-mode easymenu
easy-mmode cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 cl-preloaded nadvice button
loaddefs faces cus-face pcase macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process nativecomp
emacs)
Memory information:
((conses 16 120435 14545)
(symbols 48 9569 1)
(strings 32 28965 2841)
(string-bytes 1 952843)
(vectors 16 38276)
(vector-slots 8 804855 15451)
(floats 8 80 204)
(intervals 56 3638 189)
(buffers 984 12))
--
Best regards,
Andrey Listopadov
[report (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 18:00:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sat, 6 Feb 2021 20:33:56 +0300
>
> 1. Run emacs -q
> 2. Open some big file, in my case I've opened lisp-mode.el
> 3. Turn on fundamental-mode (optional)
> 4. Go to the end of the buffer.
> 5. Rapidly produce scroll up events from touchpad or mouse wheel
> (although it is much harder to achieve with mouse) with significant
> scroll amount. By significant scroll amount I mean continuous
> scrolling event from touchpad, which can be achieved by swiping over
> whole touchpad area very rapidly.
> 6. Observe that Emacs doesn't scroll almost at all and just waits until
> scroll events will stop. Then it scrolls correct amount.
>
> The delay I'm talking about is what bothers me.
I cannot reproduce this. Did you try "emacs -Q"?
Please load mwheel.el (NOT the .elc file!), and then profile the slow
scrolling again and show a fully-expanded profile. That might help us
understand what part of mwheel-scroll takes the lion's share of CPU
cycles.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 18:35:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Feb 6, 2021 at 8:59 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> I cannot reproduce this. Did you try "emacs -Q"?
Yes, the behavior I've described happens to me in emacs -Q (and emacs -q)
> Please load mwheel.el (NOT the .elc file!), and then profile the slow
> scrolling again and show a fully-expanded profile. That might help us
> understand what part of mwheel-scroll takes the lion's share of CPU
> cycles.
Here's whole report expanded (btw can't find if there's expand-all
feature?):
11593 91% - command-execute
11549 91% - funcall-interactively
11542 91% - mwheel-scroll
11536 91% - let*
11420 90% - condition-case
11381 90% - unwind-protect
11377 90% - let
11373 90% - cond
11372 90% - condition-case
10868 86% - funcall
324 2% - scroll-down
263 2% - jit-lock-function
255 2% - jit-lock-fontify-now
235 1% - jit-lock--run-functions
233 1% - #<compiled -0x152f649d2893cb7b>
232 1% - font-lock-fontify-region
224 1% - font-lock-default-fontify-region
132 1% - font-lock-fontify-syntactically-region
110 0% syntax-ppss
10 0% - lisp-font-lock-syntactic-face-function
7 0% - lisp-string-in-doc-position-p
1 0% forward-sexp
2 0% - lisp-string-after-doc-keyword-p
2 0% - backward-sexp
2 0% forward-sexp
35 0% - font-lock-fontify-keywords-region
17 0% - lisp--el-match-keyword
2 0% - lisp--el-non-funcall-position-p
1 0% syntax-ppss
5 0% #<compiled -0x4e6368f210a40dc>
1 0% - let
1 0% - cond
1 0% eq
1 0% font-lock-prepend-text-property
1 0%
lisp--match-confusable-symbol-character
6 0% font-lock-unfontify-region
24 0% - eval
18 0% - if
3 0% display-graphic-p
2 0% - unless
1 0% if
1 0% mode-line-eol-desc
502 3% - unwind-protect
502 3% - funcall
5 0% - scroll-down
4 0% - eval
4 0% if
4 0% - if
2 0% if
6 0% - message
4 0% - error-message-string
3 0% - substitute-command-keys
1 0% #<compiled -0x1fc73df3077c5a73>
1 0% clear-minibuffer-message
57 0% - if
50 0% - progn
46 0% - setq
39 0% - run-with-timer
33 0% - run-at-time
4 0% - timer-set-time
1 0% timer--time-setter
1 0% timer-activate
3 0% *
2 0% if
3 0% - let
2 0% - while
1 0% - consp
1 0% - setq
1 0% car-safe
49 0% - mouse-wheel--get-scroll-window
48 0% - or
47 0% - catch
45 0% - let*
44 0% - if
39 0% progn
4 0% mwheel-event-window
1 0% - delq
1 0% - delq
1 0% delq
5 0% - eval-expression
5 0% progn
42 0% - byte-code
29 0% - read--expression
2 0% - redisplay_internal (C function)
2 0% - funcall
2 0% - #<compiled 0x4f9dac7e18824a>
2 0% - gui-backend-selection-exists-p
2 0% - apply
2 0% #<compiled -0x16887ad6f3ef152d>
1 0% - frame-windows-min-size
1 0% window-min-size
976 7% - ...
976 7% Automatic GC
13 0% - timer-event-handler
13 0% - apply
13 0% - #<subr
F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_11>
13 0% - eldoc-print-current-symbol-info
13 0% - eldoc--invoke-strategy
13 0% - eldoc-documentation-default
13 0% - elisp-eldoc-funcall
13 0% - elisp--fnsym-in-current-sexp
13 0% - elisp--beginning-of-sexp
13 0% - forward-sexp
4 0% - scan-sexps
4 0% syntax-ppss
11 0% - jit-lock--antiblink-post-command
11 0% syntax-ppss
5 0% - undo-auto--add-boundary
4 0% - undo-auto--boundaries
2 0% undo-auto--ensure-boundary
3 0% - mwheel-filter-click-events
2 0% - if
2 0% eq
3 0% internal-timer-start-idle
3 0% tooltip-hide
2 0% - redisplay_internal (C function)
1 0% - funcall
1 0% - #<compiled 0x4f9dac7e18824a>
1 0% - gui-backend-selection-exists-p
1 0% - apply
1 0% #<compiled -0x16887ad6f3ef152d>
1 0% - jit-lock-function
1 0% - jit-lock-fontify-now
1 0% - jit-lock--run-functions
1 0% - #<compiled -0x152f64ab9864c87b>
1 0% - font-lock-fontify-region
1 0% - font-lock-default-fontify-region
1 0% - font-lock-fontify-syntactically-region
1 0% syntax-ppss
2 0% - #<compiled 0x1cf15f5a0be052d1>
1 0% - filter-buffer-substring
1 0% - buffer-substring--filter
1 0% - #<compiled 0x1f88987120b96adb>
1 0% apply
Also, I've attached a video of what I'm doing.
VID_20210206_211819.tar.xz
<https://drive.google.com/file/d/19dsfdY_f30FKRTGJld28wuBcJB0T8LrT/view?usp=drive_web>
--
Best regards,
Andrey Listopadov
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 18:57:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 46350 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 6, 2021 at 9:34 PM Andrey Orst <andreyorst <at> gmail.com> wrote:
>
> On Sat, Feb 6, 2021 at 8:59 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > I cannot reproduce this. Did you try "emacs -Q"?
>
> Yes, the behavior I've described happens to me in emacs -Q (and emacs -q)
I should mention again, that I'm setting
`mouse-wheel-progressive-speed' to `nil' after I'm opening emacs -Q.
Without this setting the lag still there, but it is a bit harder to
capture it in -Q mode, as buffer scrolls to upper boundary almost
instantly with that much speed produced by toucpad. With my regular
configuration the value of this variable doesn't matter.
--
Best regards,
Andrey Listopadov
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 19:03:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sat, 6 Feb 2021 21:34:29 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> > Please load mwheel.el (NOT the .elc file!), and then profile the slow
> > scrolling again and show a fully-expanded profile. That might help us
> > understand what part of mwheel-scroll takes the lion's share of CPU
> > cycles.
>
> Here's whole report expanded (btw can't find if there's expand-all feature?):
Yes, "C-u RET".
> 11593 91% - command-execute
> 11549 91% - funcall-interactively
> 11542 91% - mwheel-scroll
> 11536 91% - let*
> 11420 90% - condition-case
> 11381 90% - unwind-protect
> 11377 90% - let
> 11373 90% - cond
> 11372 90% - condition-case
> 10868 86% - funcall
> 324 2% - scroll-down
> 263 2% - jit-lock-function
> 255 2% - jit-lock-fontify-now
> 235 1% - jit-lock--run-functions
I cannot make sense out of this: this profile says that funcall takes
most of the time, and the function it calls, scroll-down, takes almost
no time? Does anyone have any idea what could be going on here?
If this is just some artifact of "M-x profile", and most of the time
is spent in scroll-down, then I'm not sure what can be done, nor why
you see something I don't. Do you use a large frame and/or a small
font? And how many mouse-wheel events Emacs receives in your
scenario, anyway?
Oh, and what happens if you raise gc-cons-threshold to a large value?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 19:06:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sat, 6 Feb 2021 21:55:58 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> I should mention again, that I'm setting
> `mouse-wheel-progressive-speed' to `nil' after I'm opening emacs -Q.
Yes, I tried that. I don't see anything abnormal except the slower
scrolling (which is expected without the progressive-speed setting).
> Without this setting the lag still there, but it is a bit harder to
> capture it in -Q mode, as buffer scrolls to upper boundary almost
> instantly with that much speed produced by toucpad.
What is the size of the buffer that it scrolls almost instantly to
BOB? How many lines?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 19:49:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Do you use a large frame and/or a small
> font?
In fact, yes, my screen is 2K, and system font scaling is set to 1.44, but
this also happens on regular 1080p screen with regularly sized font.
And how many mouse-wheel events Emacs receives in your
> scenario, anyway?
>
Sorry, how can I check that? I do think that Emacs actually receives a
metric ton of events, as scolling with mouse seems hardly lag at all, and
scrolling in termux with touch events also not as laggy.
Oh, and what happens if you raise gc-cons-threshold to a large value?
>
No difference. Note, that scrolling with scrollbars has no lag at all, so I
don't think that GC is relevant here.
I've also noticed that scrollin with scrollbar has (sit-for 0) in the body
of the scroll function, and IIRC mwheel-scroll doesnt sit at all. maybe
because of that it consumes too many inputs?
I wonder if you could send tons of scrolling inputs via xdotool or smth
like that on Linux?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sat, 06 Feb 2021 20:04:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sat, 6 Feb 2021 22:47:55 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> And how many mouse-wheel events Emacs receives in your
> scenario, anyway?
>
> Sorry, how can I check that?
Add a call to 'message' to mwheel-scroll, and have it show a counter
that counts up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 17:24:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 46350 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 6, 2021 at 11:03 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > And how many mouse-wheel events Emacs receives in your
> > scenario, anyway?
> >
> > Sorry, how can I check that?
>
> Add a call to 'message' to mwheel-scroll, and have it show a counter
> that counts up?
I've did as you've suggested. When scrolling buffer of 1405 lines from
bottom to the top (while emacs is unresponsive) mwheel-scroll function
seems to be called about ~1351 times. Single fast flick over touchpad
produces ~40 calls to mwheel-scroll.
Adding (sit-for 0) at the start of the function doesn't have any effect.
> What is the size of the buffer that it scrolls almost instantly to
> BOB? How many lines?
1405 lines. I'm testing this on bundled lisp-mode.el
--
Best regards,
Andrey Listopadov
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 17:50:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sun, 7 Feb 2021 20:23:09 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> > Add a call to 'message' to mwheel-scroll, and have it show a counter
> > that counts up?
>
> I've did as you've suggested. When scrolling buffer of 1405 lines from
> bottom to the top (while emacs is unresponsive) mwheel-scroll function
> seems to be called about ~1351 times. Single fast flick over touchpad
> produces ~40 calls to mwheel-scroll.
1350 calls during what time, approximately? less than a second?
I don't think Emacs can scroll so fast, one line at a time. Note that
when you scroll with the scroll-bar, Emacs doesn't call
scroll-up/down, it just goes to a suitably calculated buffer position.
Which is why scroll-bar scrolling is much faster. But I don't see how
we can do something similar with the mouse-wheel, since it doesn't
allow to calculate the buffer position to go to; Emacs needs to do
that calculation itself, and that what makes the scrolling so much
slower.
> > What is the size of the buffer that it scrolls almost instantly to
> > BOB? How many lines?
>
> 1405 lines. I'm testing this on bundled lisp-mode.el
Which explains why it scrolls in one go: 1405 ≅ 1350.
So, once we've established that the touchpad injects 1-line scroll
requests at such a high rate, what else needs to be investigated here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 18:34:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 46350 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 7, 2021 at 8:49 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 1350 calls during what time, approximately? less than a second?
If you've watched the video I've linked you can get a sense of what
time it takes -- about 15 seconds. Or more if I continue swyping
rapidly, since Emacs just sits at the bottom eating all input until I
stop.
Touchpad generates about 20-30 inputs per swipe, so I think ~90 inputs
is maximum human can produce in 1 second
> I don't think Emacs can scroll so fast, one line at a time. Note that
> when you scroll with the scroll-bar, Emacs doesn't call
> scroll-up/down, it just goes to a suitably calculated buffer position.
> Which is why scroll-bar scrolling is much faster. But I don't see how
> we can do something similar with the mouse-wheel, since it doesn't
> allow to calculate the buffer position to go to; Emacs needs to do
> that calculation itself, and that what makes the scrolling so much
> slower.
Can Emacs poll mouse events less frequently? Maybe some libinput stuff
needs tweaking?
> > > What is the size of the buffer that it scrolls almost instantly to
> > > BOB? How many lines?
> >
> > 1405 lines. I'm testing this on bundled lisp-mode.el
>
> Which explains why it scrolls in one go: 1405 ≅ 1350.
>
> So, once we've established that the touchpad injects 1-line scroll
> requests at such a high rate, what else needs to be investigated here?
There I was talking about progressive speed turned on, as it builds up
almost instantly with my touchpad producing 30 inputs per swipe.
--
Best regards,
Andrey Listopadov
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 18:45:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sun, 7 Feb 2021 21:33:25 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> On Sun, Feb 7, 2021 at 8:49 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 1350 calls during what time, approximately? less than a second?
>
> If you've watched the video I've linked
I cannot watch that video, sorry. But I don't think it matters, see
below.
> you can get a sense of what
> time it takes -- about 15 seconds. Or more if I continue swyping
> rapidly, since Emacs just sits at the bottom eating all input until I
> stop.
I didn't ask how much time it takes Emacs to process the inputs. I
asked how much time did it take you to generate them by moving your
finger on the touchpad. I very much doubt the answer to that is 15
sec.
> Touchpad generates about 20-30 inputs per swipe, so I think ~90 inputs
> is maximum human can produce in 1 second
~100 1-line scrolls per second is also a lot, for what Emacs must do
to scroll.
> Can Emacs poll mouse events less frequently?
Emacs doesn't poll the mouse. The mouse events are received from the
X event queue, together with all the other events: keyboard input,
expose events, etc. We read the events from X and then process them
one by one.
> > So, once we've established that the touchpad injects 1-line scroll
> > requests at such a high rate, what else needs to be investigated here?
>
> There I was talking about progressive speed turned on, as it builds up
> almost instantly with my touchpad producing 30 inputs per swipe.
Sorry, I don't understand: what builds up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 18:53:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> I didn't ask how much time it takes Emacs to process the inputs. I
> asked how much time did it take you to generate them by moving your
> finger on the touchpad. I very much doubt the answer to that is 15
> sec.
>
Yes I was talking about me inputting scrolling events for about ~15 secs.
I've rewatched the video and I'm continuously swiping over touchpad for
about ~10 seconds, and Emacs updates position ~5 seconds after I stopped.
> There I was talking about progressive speed turned on, as it builds up
> > almost instantly with my touchpad producing 30 inputs per swipe.
>
> Sorry, I don't understand: what builds up?
>
Scrolling speed. With progressive speed turned on it is impossible to use
touchpad because after single swipe the speed builds up so much resulting
in point immediately jumping to beginning/end of buffer.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 19:06:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Sun, 7 Feb 2021 21:52:22 +0300
> Cc: 46350 <at> debbugs.gnu.org
>
> > There I was talking about progressive speed turned on, as it builds up
> > almost instantly with my touchpad producing 30 inputs per swipe.
>
> Sorry, I don't understand: what builds up?
>
> Scrolling speed. With progressive speed turned on it is impossible to use touchpad because after single
> swipe the speed builds up so much resulting in point immediately jumping to beginning/end of buffer.
With such a rate of input events, isn't that expected?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 19:39:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 46350 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Scrolling speed. With progressive speed turned on it is impossible
>> to use touchpad because after single
>> swipe the speed builds up so much resulting in point immediately
>> jumping to beginning/end of buffer.
>
> With such a rate of input events, isn't that expected?
I don't use either a touchpad or a mouse with a scroll button... but I
seem to remember there being support for coalescing events from a scroll
button in Emacs, at least? Am I misremembering?
If I'm not, could this also be used in this case, perhaps?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 19:48:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Andrey Orst <andreyorst <at> gmail.com>, 46350 <at> debbugs.gnu.org
> Date: Sun, 07 Feb 2021 20:37:46 +0100
>
> I don't use either a touchpad or a mouse with a scroll button... but I
> seem to remember there being support for coalescing events from a scroll
> button in Emacs, at least? Am I misremembering?
That's the progressive scroll speed, no?
If not, what did you mean by coalescing here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 20:55:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 46350 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I don't use either a touchpad or a mouse with a scroll button... but I
>> seem to remember there being support for coalescing events from a scroll
>> button in Emacs, at least? Am I misremembering?
>
> That's the progressive scroll speed, no?
Oh, yeah. Sorry. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 22:17:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 46350 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 07, 2021 at 09:52:22PM +0300, Andrey Orst wrote:
> >
> > I didn't ask how much time it takes Emacs to process the inputs. I
> > asked how much time did it take you to generate them by moving your
> > finger on the touchpad. I very much doubt the answer to that is 15
> > sec.
> >
>
> Yes I was talking about me inputting scrolling events for about ~15 secs.
> I've rewatched the video and I'm continuously swiping over touchpad for
> about ~10 seconds, and Emacs updates position ~5 seconds after I stopped.
>
> > There I was talking about progressive speed turned on, as it builds up
> > > almost instantly with my touchpad producing 30 inputs per swipe.
> >
> > Sorry, I don't understand: what builds up?
> >
>
> Scrolling speed. With progressive speed turned on it is impossible to use
> touchpad because after single swipe the speed builds up so much resulting
> in point immediately jumping to beginning/end of buffer.
This all sounds awfully like the problems we had with the touchpads on
macOS.
On macOS the OS sends inputs with a number of pixels that it expects
the application to scroll, this means it can send hundreds of touchpad
events in a few seconds, but the application is only supposed to
scroll, perhaps, a few tens of lines.
What we do in the NS code is count up the number of pixels and only
send the event to Emacs once it reaches some predetermined "line
size".
I didn't think X worked this way, though, so perhaps it is some
libinput setting.
Or are you using XWayland, which may behave differently than standard
X?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 22:23:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> I didn't think X worked this way, though, so perhaps it is some
> libinput setting.
>
> Or are you using XWayland, which may behave differently than standard
> X?
>
I'm using both X (manually selected) and XWayland on two different machines
(both with GNOME Shell). Fedora 32 and 33 respectively if that matters.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 22:25:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 46350 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 08, 2021 at 01:22:12AM +0300, Andrey Orst wrote:
> >
> > I didn't think X worked this way, though, so perhaps it is some
> > libinput setting.
> >
> > Or are you using XWayland, which may behave differently than standard
> > X?
> >
>
> I'm using both X (manually selected) and XWayland on two different machines
> (both with GNOME Shell). Fedora 32 and 33 respectively if that matters.
And they all behave the same?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Sun, 07 Feb 2021 22:31:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> And they all behave the same?
>
Yes. Sorry, should have mentioned that in the first place.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Mon, 08 Feb 2021 10:13:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Also, for some reason scrolling to the buffer's end has much less lag
compared to scrolling to the beginning of the buffer. It's still laggy, but
more manageable
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Mon, 08 Feb 2021 14:37:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
And horizontal scrolling is not laggy with touchpad at all. Well, at least
rapid left and right swipes on touchpad aren't creating enormous cpu usage.
So, to summarize:
- scrolling to buffer end (down) is less laggy than scrolling to buffer
start (up)
- horizontal scrolling isn't laggy at all
- this can be achieved with mouse if you roll it with mouse wheel over the
table very fast
If I can produce more information, maybe stack traces, or more in-depth
profiling please guide me with some instructions. This issue bothered me
for about 2 years, just finally decided to report it.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Mon, 08 Feb 2021 15:20:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Mon, 8 Feb 2021 13:12:09 +0300
>
> Also, for some reason scrolling to the buffer's end has much less lag compared to scrolling to the beginning
> of the buffer. It's still laggy, but more manageable
Scrolling back to the beginning of buffer is more CPU-intensive,
because the functions used for scrolling can only move forward in the
buffer. So what you see is quite expected.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Mon, 08 Feb 2021 15:29:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 46350 <at> debbugs.gnu.org (full text, mbox):
> From: Andrey Orst <andreyorst <at> gmail.com>
> Date: Mon, 8 Feb 2021 17:35:51 +0300
>
> And horizontal scrolling is not laggy with touchpad at all. Well, at least rapid left and right swipes on touchpad
> aren't creating enormous cpu usage.
Horizontal scrolling isn't anywhere as expensive as vertical one.
> - scrolling to buffer end (down) is less laggy than scrolling to buffer start (up)
> - horizontal scrolling isn't laggy at all
> - this can be achieved with mouse if you roll it with mouse wheel over the table very fast
>
> If I can produce more information, maybe stack traces, or more in-depth profiling please guide me with some
> instructions. This issue bothered me for about 2 years, just finally decided to report it.
Isn't there some way to control the rate with which the touchpad sends
its events to applications? Some system-wide setting, perhaps?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46350; Package
emacs.
(Mon, 08 Feb 2021 15:32:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 46350 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Isn't there some way to control the rate with which the touchpad sends
> its events to applications? Some system-wide setting, perhaps?
>
As far as I know - no. Wayland didn't standardized this yet, and even for X
there are debates on how to set this properly. Or at least that's what I've
heard. Gnome doesn't have scroll speed settings neither for mouse nor for
touchpad. KDE also lacks this setting AFAIK.
>
[Message part 2 (text/html, inline)]
This bug report was last modified 4 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.