On 29.09.16 22:08, Sergey Malenkov wrote:
Just to clarify, if you perform slow scroll gesture and the accumulator will
be less than threshold means that you should not scroll, no? Because the sum
of overall scroll events are less than one line. The fact that you need to
"move a certain minimum distance before the scroll takes effect" is OSX bug,
I wonder how the native app works, do they have the same "deadzone"?
Native apps support per-pixel scrolling, so their "deadzone" is 10 times less.
It depends from the application, just checked on the list of emails in
the Thunderbird which have small "deadzone". I think we should not do
any magic in this files. only get native event and post it to upper
level(the int value should be accumulated) And this is responsibility of
upper level to do some work depending from the MouseWheelEvent.
So I suggest to process the phase end to align accumulated value.
It adds an ability to scroll with short scroll gesture.
If you align accumulated value to bigger integer,
it also aligns scrolled lines automatically
when we support per-pixel scrolling.
Per pixel scrolling should depend from the preciseWheelRotation, otherwise
on the retina display you will be able to scroll only by the units(2
pixels).
In Java lists and trees a unit is a line (~12 or ~24 pixels)
This how these component implemented and I think we can change or tweak
this. If you run SwingSet2 demo on "Scroll Pane Demo" you will see that
it is possible to scroll per units(every pixel on non-retina/every two
pixels on the retina).
--
Best regards, Sergey.
