Volume slider acts weird on laptop trackpad

[drakinite]

Hi,
I just noticed that on laptops, the volume slider is pretty hard to control on laptop trackpads. I think it's because of the scrolling acceleration that the UI generally uses?

Firstly, I don't know if this can be fixed, but it's a bit weird having to scroll upwards to move the volume down, and vice versa. If possible, it would be nice if my finger movements reflected the direction the volume is being changed (up/down).

Secondly, when I move my fingers slowly on the trackpad, the volume does not change at all. I have to "flick" quickly up and down to move the volume, and then the volume quickly goes all the way up. I think it's some sort of problem with the trackpad acceleration.

Recording: https://youtu.be/hfjK1p0cy6M

[Peke]

Hi,
I tried today on a friends Laptop and he had Synopsis Track pad driver installed. It has setting to control finger gestures eg. Two finger scroll 1, 3 lines, 1 Page, Acceleration If it was set to Acceleration and I flip two fingers then Win 10 Volume overlay went from 100-0 or via verso.

Windows 10 Overlay

[drakinite]

I'm just talking about the MM5 volume slider, not the Windows volume slider.

[Peke]

Hi,
For me they acted the same in tests today, so I am not sure it is MM problem

[drakinite]

Tbh the Windows volume slider on the top-left corner of the screen doesn't even work with touchpad scrolling for me. But the one that you get when clicking the taskbar icon works fine: https://youtu.be/N1u0XCoFVwc

But also, the touchpad scrolling on MM4's volume slider is very good. It's a tad sensitive, but it works. Maybe it's possible to do some magic with the DOM scroll event, to make sure that the volume bar doesn't get stuck on a touchpad?

[drakinite]

So it looks like it's basically impossible to unequivocally tell touchpad input apart from mouse input, so my hope of having a scroll bar that logically matches the direction of finger movement is (probably) down the drain.
https://stackoverflow.com/questions/107 ... javascript

However, the same stackoverflow thread shows some logic for detecting (and ignoring) a high amount of concurrent mousewheel events, which denote a trackpad. Detecting and ignoring the repeated mousewheel events could help to prevent the wild up-and-down flicking of the volume bar.

You know... Since touchpads already have great precision drivers, why don't we just make the volume slider go in steps of 1 instead of 5 when it's being controlled by a touchpad? This would be pretty easy in theory. The scroller seems to calculate the delta by dividing the wheelDelta by 120, then multiplying by the step value.
In the volume slider's case, you could check if wheelDelta is less than, say, 60 (They seem to be pretty low unless you scroll pretty fast), then moving it in steps of 1-5, depending on the value. It would also probably work if it's floored to 1, but it wouldn't be as smooth-feeling.

Edit: I just made a prototype in slider.mouseWheelHandler that does that last bit (but without the multi-event rejection), and it honestly works decently. It might break other sliders, I'm not sure, but for the volume it's quite nice already.