"Movement to scroll" improvements

[Killy]

1. When I move the ball on my trackball, it is not exactly in X or Y direction. When I have "Lock to Y axis" checked, scrolling might behave not quite as good as I'd like it too - I have to check if I hold trackball properly.
I think it might be better experience if you take into account not just Y displacement but displacement vector length (sqrt(dx^2+dy^2)).

2. Some kind of acceleration curve would be nice to have. It looks like I'm not able to perform an equivalent of one or two discrete mouse wheel "clicks". It either generates way too many events from small move, or way too slow for general use (and still too many events on small move).
It happens when I'm trying to adjust volume in media player.

[phil]

1. I can try that, but because the movement is generally in single pixels (1, 2 etc) in both directions, I'm not sure it will help much.

This also impacts 2, the problem is because the cursor does not move, the individual movements are very small, generally no matter how much you move the ball/mouse and trying to accelerate that tiny number does not help/do much. Having said that, if you have any fancy maths to implement acceleration, let me know - its not my strong point!

[phil]

I've added direction vector (1) in 2.17 beta 15 - let me know if it helps.

[Killy]

1. That really feels better. Thanks.
Also, direction vector has kind of subpixel resolution except when movement happens straight along the axis.

2. I need something to start with - that's where open source would've helped. I need to know what current code does to calculate scroll amount from (dx,dy,sensitivity).

[phil]

1. I'm glad that worked - it was a nice simple change...

2. Its *very* crude and a bit of a mess right now...

Basically it takes the X,Y pixels difference between the point MTS is activated (clicked) and the current position (bear in mind the cursor does not actually move so the numbers are small each time).

It then multiplies these numbers by an "acceleration factor" (which clearly isn't sufficient/working) which is increased by 0.25 every time a new movement message is received - I guess this is where we need to concentrate, perhaps with a logarithmic multiplier rather than just increasing by .25 each time.

The numbers are then converted into lines/columns to scroll.

Thanks,
Phil

[Killy]

Ok. I made this playground/POC thing: http://mxii.eu.org/demo/scroll/
(Drag or scroll over page. Green is for mouse input, red for emulated scroll, blue for actual scroll.)

And code gist for convenience: https://gist.github.com/KillyMXI/555ada ... 73146ef443
(See comments around important parts, namely touchpadAccelerationCurve, emulateScroll, xyToMovementAmount and mouseDragged functions).

I may write a blog post about the idea and various observations later, but the most important things so far:

• with this playground I looked how scroll works on various devices and have realized that touchpad on my laptop (and every laptop I guess) has the same issue - it spam scroll events, with higher frequency even. But volume control in media players works on per-event basis. Have to do something with spamming.
• scroll produced by XMBC looks quite noisy, jumping all over the place, despite mixing/filtering. Sensitivity acts like multiplier on both small and big input alike.
• mixing current input with previous produces horrible lag/overshoot, when scroll direction is kept for a while after movement direction is changed.
• actual scroll wheel (ratchet wheel) produces scroll events once per click, when optical sensor inside the device is triggered. Scroll event has fixed scroll amount (no smooth scroll).

So I made an implementation of both touchpad- and ratchet wheel-like behaviour, and then combined them.

• It doen not spam scroll events on small inputs but wait for accumulator to fill - should be much better on volume controls (see red bars on demo page);
• acceleration curve on bigger inputs (I wonder how it will play with different system mouse acceleration settings but didn't explore that. Should not be any issue);
• negative effects of filtering seemingly absent in combined mode, same as for ratchet wheel;
• using only Y component or vector length might not be all that relevant after all, once everything else is working properly, and vector length looks slightly more noisy. It looks like touchpad driver in my laptop is doing something fancy on that matter when emulating scroll but I can't deduce what exactly. I end up with compromise solution, where only half of orthogonal input is used.

As the result, there are plenty of sliders to play with. Default values are something that looks about right for me, but JavaScript wasn't the best choice for experiments, since I can't override mouse movements and look at it in closer to real conditions (UPD: added Pointer Lock support, for browsers that will agree to use it). It can be boiled down to fewer controls after final implementation is decided, but it's unlikely to have just single "sensitivity" slider.

Demo is made with vertical scroll in mind. Tell me if there are any difficulties in adapting this to two-dimensional scroll.


P.S.: Some touchpads have really fancy circular infinite scroll, but I'll left that excercise for another time. It's not as easy to perform on trackball as on touchpad, and the math will be more complex too.

P.P.S.: Another issue with browser demo - every browser interpret mouse movements differently. Even Chromium-based ones like Opera and Vivaldi.

[phil]

Wow that is pretty in depth - I will take a look in detail when I get a moment (probably at the weekend) and let you know how I get on.

Thanks,
Phil

[injtsvetkov]

Basically it takes the X,Y pixels difference between the point MTS is activated (clicked) and the current position (bear in mind the cursor does not actually move so the numbers are small each time).

It then multiplies these numbers by an "acceleration factor" (which clearly isn't sufficient/working) which is increased by 0.25 every time a new movement message is received - I guess this is where we need to concentrate, perhaps with a logarithmic multiplier rather than just increasing by .25 each time.

Instead of adding 0.25, can you make it multiply the previously used "acceleration factor" by 1.1 or 1.2 or whatever corresponds to the sum of the (initial "acceleration factor" + 0.25)

Example:

Adding 0.25 (if the initial acc. factor is 5): 5 > 5.25 > 5.5 > 5.75 > 6 > 6.25 > 6.5 ......

Multiplying by 1.2 (initial acc. factor is 4): 4 > 4.80 > 5.76 > 6.91 > 8.29 > 9.95 > 11.94 ......

[phil]

Yes that may be the simplest solution... I'm a little wary of making too many changes because I want to release 2.17 but that is a really simple one that cant go too wrong ... Will see. I was going to look at all of this on Saturday but was ill and didn't manage much at all this weekend .

[Killy]

which is increased ... every time a new movement message is received

I don't think this will produce reasonable result in any case. This way it depends on time (event counter), not actual movement amplitude. Therefore I can't make it faster by moving faster - event rate is limited.

I think acceleration should not depend on previous history. The only thing needed is an acceleration curve, that translates current movement amount into current scroll amount. That's exactly what I done in my demo (for touchpad-like behaviour). This, on it's own, is even simpler than existing behaviour.

But more that that, I want a proper small input handling. That can't be addressed with just an acceleration curve, and, by design, can't work with time-dependent acceleration. My solution is also in the demo. It's not difficult either. Most tough choice will be to decide which numbers can be baked in and which should be exposed to user for tweaking. (I'd like to see a text config file for advanced tweaking).

[phil]

Well all settings are in the XML file (which is text) so so long as its configurable then thats how that will work (eventually).