IssueTracker

quickly looked at the test failures. It seems like our regular non-velocity testing with

down()
moveBy(40f, 0f)
up()

Is no longer results in 0 velocity, hence many of the tests failed that relied on that.

I think (cc-ed Jelle to verify) that the way we ensured this is my having moveBy() and up() reporting the same pointer position to velocity tacking, where velocity tracker would treat it as a signal to return 0 velocity.

Is that an intentional change in the algorithm or a cornercase we need to handle?

Right, the problem is caused by VelocityPathFinder. The 'lsq2' algorithm is essentially hardcoded there. I looked into it a bit, I'm able to pass some tests by changing the impl to use a couple of lines instead of parabola. However, it still does not work for all cases.

To solve the arbitrary "here's a start x and an end x, a time, and a velocity, figure out the path to achieve the desired velocity" problem is not very straightforward. It's not possible to solve with just 1 or 2 lines. You may need a non-linear curve. That would require re-deriving a differential equation for the impulse algorithm to solve for a specific function. Im still looking into it.

Yes, when testing swipes with specific velocities, the sequence of touch events is very much dependent on the algorithm of the velocity tracker. If that algorithm changes, so must the injected touch events.

Thanks for taking a look at the VelocityPathFinder, Siarhei. The current implementation basically reverse engineered the algorithm of VelocityTracker and derived an equation for it. If that is no longer possible, or is blocking you unreasonably, I think it's okay to relax the guarantees made by the VelocityPathFinder, as long as we have (1) some kind of approximation that works in most cases and (2) if it doesn't work we can make suggestions how to adjust the parameters to make it work (e.g. "try a shorter duration" or "do the swipe over a longer distance"). But even then, the latter requirement can be postponed if it is infeasible. I scheduled a meeting this Friday so we can discuss.

Perfect, thanks Jelle.

I thought about this problem some more.

First, you can always achieve a certain velocity between two points if you are able to control time, by using a straight line with a fixed velocity going from start to finish.

However, with the current APIs, a time is provided, as well. That means we must add some more complex behaviour, similar to the current "flat line followed by a parabola". Adding two lines (a flat line with another straight line) works in most cases. However, it won't always work:

1. If you are doing sampling, and you don't catch the entirety of the rising line over 100 ms, then it's possible that the velocity tracker would effectively see a rising line for less than 100 ms, and will thus not achieve the same velocity.
2. Even without sampling, some of the provided inputs are such that the motion might have to first go backwards sufficiently (so instead of initial flat line, it would be a negative-sloping line) in order to achieve the desired final velocity, if you want a high velocity. This would not satisfy the requirement that the function is monotonically increasing.
3. A piecewise-defined linear function also won't work due to sampling, since we are bound to miss some of the kinks in such a curve.

I will upload a "two-line" solution tomorrow that at least solves some of the presubmit failures to provide a better idea of what that looks like.

However, if we wanted to just change the VelocityPathFinder impl without the other tests, we would have to find some smooth function that ideally could be arbitrarily sampled, and would still result in roughly the requested velocity. From my investigations, it would have to satisfy the following: vfinal = integral_over_path(f'f'')(some constants). It's pretty easy to solve this for the case of f(t) = ax^2+bx+c, but I was not sure how to deal with the initial condition, since it's harder to define it in the smooth approximation. I think a simpler approach could be to do some numerical fitting, like picking a few monotonically increasing smooth functions (polynomial/sqrt, sin, exp, etc), and then tune them to achieve the desired velocity. Since this is only used in tests, we don't care about performance, so we can use some brute force approach. I haven't tried this yet, but I think it should work, if we want to go down that path. One benefit here would be that this approach would be immune to any future velocitytracker impl changes. Let's discuss more on Friday.