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