GNU bug report logs -
#46350
28.0.50; touchpad-scrolling-eats-lots-of-cpu-samples
Previous Next
Full log
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
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.