[zamalek]

Uh no. This is completely wrong.

Ever tried to play really old games like Worms 1 on anything faster than 100MHz? They are "framerate locked" which means that a higher framerate makes everything go faster. So if you used that function on a 120hz display everything would run at twice the speed (assuming it's designed to run on 60hz). This is why things like Dos Box let you run at a lower emulated CPU frequency: so that you can slow things down so that these games are playable.

In terms of UI animation the most sensible thing to use is Euler Integration (pronounced "oiler").

Euler Integration is based off of Distance = Speed / Time. Basically what you need to do is remember the "last time" the function was called (using a high resolution timer) and find the difference between that and the current frame. This gives you the "Time" in Euler Integration, your "Speed" should be a fixed constant (e.g. 1 pixel per second). Then simply add Distance / Speed to your current X value.

Things git a tad bit complicated to ensure that you don't "overshoot" your target position, but it's nothing simple high-school algebra can't solve (that's the nice thing about Euler Integration, it's all high school Mathematics and Physics).

Techniques like ease-in/ease-out are easy to do (using the difference in distance between the current point and starting/ending points use base your speed off of that), all using high school algrebra.

I wouldn't bother with Verlet or Runge-Kutta: it is just UI animation after all - you aren't going for very accurate results like games do. "Real" physics engines also have the problem of not being able to guarantee deterministic results.

[taybenlor]

Sorry, I'm not quite sure what you're saying is wrong. I understand your point about physics engines perhaps being the wrong tool here, and I can see that. But the main focus was on how the standard tooling for UI animations is incapable of modelling movement with dynamic "distances" (I put distances in quotes because you could be transitioning colour, height, scale or any other attribute of the object).

[zamalek]

The solution presented is incorrect. I can't explain it any more than what I already said.

While he is correct about the fact that standard tooling doesn't deal with "distances", he must at the same time give the right solution.

By the way, another more direct way to get it right would be to solve S=D/T for T and hand that to the UI framework. I'm not sure what language/framework he is using but here is the general idea:

speed = 10; start = 0; end = 100; time = (end - start) / speed;

circle.left = start; animate duration: time { circle.left = 100 }

Which in itself has very little to do with a physics engine, but won't result in a customer logging a bug about how things are behaving strangely on their 120hz monitor.