I want to apologize for this tweet/toot, depending on where you read this. I was in a really bad mood amplified by a sleep deprivation, and should have just not said anything. Hope nobody got offended by that. :(
Last call for GUADEC 2020 BoF and workshop submissions! If there's a GNOME or FOSS related topic you'd like to include in the schedule tell us your idea by the end of today.
#GUADEC #OpenSource #FOSS
There is one day left to submit your GUADEC 2020 BoF and workshop requests. If you have a GNOME or free software related idea you'd like to talk about submit it by July 11!
#FOSS #OpenSource #GUADEC
@vancha Well, so far I got one response on twitter, and they couldn't reproduce it: the last delta is like 3 times lower and not like 100 times lower than the others.
The first person*
So if anybody has elantech touchpads, would be helpful if you can provide me some libinput recordings.
So I went ahead and implemented it. But unfortunately, that's still not nearly enough to fix it, so it would be awesome to know if this also happens on other elantech touchpads, or maybe it's something weird on that particular laptop.
Now, of course I'm not the person to have stumbled on this. Kinetic scrolling in GTK dealed with the same issue long before. It tracks a history of scroll deltas from the last 150ms and sums them. This seems like a good solution: we smooth the bad event out.
So, I got a report from a person with an elantech touchpad that the gesture was way too stiff. We did some investigation, and the velocity was like 100 times lower than it should be. And surely enough, it was what I just described: an event with very low deltas at the end.
Previously the swipe trackers I wrote used delta from the last non-(0, 0) event, and the times from the last 2 events. It was good enough at the time, but it means that if there's a scroll event with low, but still not zero deltas at the end of the swipe, things break.
Now, how the swipe looks like? We get lots of scroll events, each of them has time and (x, y) deltas. At the very end we get an event with (0, 0) deltas, and that's a signal to stop tracking, calculate the velocity, and notify the users to start an animation.
So if the velocity is calculated incorrectly, it's not too big deal.
However, with the new approach we actually care a lot about this value, and if it's too low, it might lead to a situation where you swipe very hard and yet scroll just a couple pages instead of like above.
The crucial part here is determining swipe velocity after we lift the fingers. With the old approach we mostly cared about its direction and whether it's high enough or not.
Of course it was also used to determine the animation duration, but it's aggressively clamped.
Context: I'm reworking the swipe trackers in libhandy/gnome-shell/webkitgtk to use a more physics-based approach for deciding whether to finish or cancel swipe, and to optionally allow swiping through more than one page at once for HdyCarousel.
Umm, this was supposed to be for twitter only, but whatever.