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