bug#35389: 27.0.50; [PATCH] Emacs on macOS sets mouse-wheel variables directly

[Alan Third]

On Sun, May 12, 2019 at 05:36:50PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 12 May 2019 12:05:04 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: rpluim@gmail.com, 35389@debbugs.gnu.org, npostavs@gmail.com
> > 
> > Unfortunately we can’t just treat each of these NSEvents as a request
> > to scroll a single line as we can receive many small requests very
> > quickly. This is what Emacs used to do and it was basically useless.
> > The slightest two finger drag on the trackpad could result in Emacs
> > scrolling several pages.
> > 
> > What the current code does is add those pixel values up until they
> > reach a certain value, then send Emacs an event telling it to scroll.
> > Unfortunately those pixel values include a built‐in acceleration
> > factor, so the more the user drags their fingers across the trackpad,
> > the higher the pixel values will be, proportionally. We can’t disable
> > that, and as far as I can tell the user can’t even disable it for the
> > whole system.
> 
> Is the algorithm used by the system to "accelerate" known?  If so,
> could we "un-accelerate" those values, by scaling them back to the
> original amount of dragging received from the user, as if acceleration
> was disabled?  Then we could apply our own acceleration as on other
> platforms.  Would that work?

I don’t think there’s a published algorithm. Generally Apple would
rather we all conform than do our own thing. After some thought I’ve
remembered that it’s possible to pick up the touch events at a lower
level, so it may be possible to do a comparison and try to reverse
engineer it. Or just bypass their scrolling completely. I’m not sure
how practical that would be though.

I hope your other questions were answered in the discussion with Tak,
so I won’t retread that ground here.
-- 
Alan Third