bug#50269: 27.2; Request: use GTK continuous scroll events for smooth touchpad scrolling

[Eli Zaretskii]

> From: Alexander Huntley <huntley.alexander@gmail.com>
> Cc: 50269@debbugs.gnu.org
> Date: Mon, 30 Aug 2021 22:26:45 +0100
> 
> pixel-scroll-mode may shift the display one pixel at a time, but it
> also "snaps" the display to certain larger intervals, (integer numbers
> of lines).

I don't think I follow: what is this "snapping" you are alluding to
here?  Can you tell me how to reproduce this snapping, so I could
understand better the problem you have in mind?

> If we could use the more precise/frequent data actually coming from
> the touchpad, then the user could control the scrolling more precisely:
> instead of scrolling by n lines, the user could scroll by as little
> as a single pixel at a time.

The scrolling, whether pixel-wise or not, is performed by the Emacs
display engine; the scroll commands themselves just tell the display
engine where in buffer text to start the display of a window, and with
what "shifting offset" in pixels to display that text.  So I don't see
how using some different/more precise data will help, if all that data
tells Emacs is by how many pixels to scroll, because the actual
scrolling will still be performed by the same display engine.  If the
display engine is unable to scroll smoothly, for some reason, using
different data source to compute how many pixels to scroll will not
help.

So we must first understand what is wrong with pixel-scroll-mode,
because all it does with the "normal" (a.k.a. "imprecise") scroll
commands coming from the touchpad is compute how many pixels to
scroll, and the default is AFAIR to scroll a small number of pixels
per wheel notch (you can customize it to make it exactly 1 pixel).

Therefore, I hope you could help us understand what is wrong with the
pixel-wise scrolling in the display engine, as it is used by
pixel-scroll-mode.  TIA.