Re: master e37eb7f: Add support for pixel wheel deltas on NS

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Nov 2021 17:37:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How to compute the amount of pixels for a given amount of wheel delta?
> 
> I don't know, but I will try to ask some people I know who know
> something about this.

Thanks.  But if this conversion is arbitrary (see below), I think I
know how to implement the MS-Windows version of "arbitrary".

> > The wheel delta on MS-Windows is reported in abstract units, not
> > directly related to any pixels, AFAICT.  I don't see the logic of the
> > conversion to pixels documented anywhere in the X or NS code, and the
> > comments, such as they are, make no sense at all to someone who knows
> > nothing about X mouse-wheel handling.  In xterm.c, it seems like some
> > kind of query of the device "valuators" (whatever that is) is being
> > used?
> 
> On X, the states of the mouse wheels in each axis are stored as absolute
> values inside "valuators" attached to each mouse device.  To obtain the
> delta of the scroll wheel from a motion event (which is used to report
> that some valuator has changed), it is necessary to iterate over every
> valuator that changed, and compare its previous value to the current
> value of the valuator.
> 
> Each individual valuator also has an "interval", which is the amount you
> must divide that delta by in order to obtain a delta in the terms of
> scroll units.
> 
> This delta however is still intermediate, to make driver implementations
> easier.  The XInput developers recommend the following algorithm to
> convert from scroll unit deltas to pixel deltas:
> 
>   pixels_scrolled = pow (window_height, 2.0 / 3.0) * delta;

All of this should be in comments in xterm.c.

Btw, the code calculates pixels_scrolled when it is not yet clear that
the value will be used, which is a waste of cycles, AFAICT.  How about
moving this closer to where the value is actually used?

In any case, are you saying that the conversion to pixels is somewhat
arbitrary?  And that users of X based systems have no control on this
conversion, i.e. users cannot determine the pixel equivalent of each
"delta"?

> > And on NS, it seems like the delta is already reported in pixels?
> 
> Yes.  The PGTK port can do something similar if it gains support for
> this, as GTK also reports it in pixels directly.

Same question here: do users have any system-wide control on the
conversion to pixels under these environments?