Smoothed Delta times on Android and overall improvements

[obigu]

Graphics has 2 different methods to get delta time, float getDeltaTime() and float getRawDeltaTime();. According to java docs, the difference is that getDeltaTime() "Might be smoothed over n frames.".

Checking all backend Graphics implementations, the only backend that does smoothing on the delta is the Android backend, that applies a simple size 5 window mean. This is probably due to legacy reasons when libGDX was created some Android devices were really unrealiable (we're talking Android 1.5 or 1.6) and my guess is that this was a workaround for those old devices with very inconsistent delta times.

Averaging the delta over 5 frames has a significant impact on how the game behaves during lag spikes. Let me show with an example.

Imagine we have the following sequence of Raw delta times
1/60 1/60 1/60 1/60 1/60 1/5 1/60 1/60 1/60 1/60 1/60

In every backend except from Android, in a typical setup in which delta is capped to 1/30 (Scene2D does that by default) the resulting deltas used by the game would be
1/60 1/60 1/60 1/60 1/60 1/30 1/60 1/60 1/60 1/60 1/60 1/60
In which only the 1/30 frame would have a "slow motion" distortion caused due to real elapsed time being higher than delta time

On Android, on the other hand, we would get
1/60 1/60 1/60 1/60 1/60 1/30 1/30 1/30 1/30 1/30 1/60
In which the first 1/30 frame would be distorted exactly like before but the next 4 1/30 ones they would be "fast forward" (as if it was catching up).

Understanding that

• Different games have different needs (not the same a multiplayer racing game than a puzzle game) and may want to deal differently with lag spikes or delta inconsistencies.
• It is a complex topic and there's not a perfect solution. See for example https://blogs.unity3d.com/2020/10/01/fixing-time-deltatime-in-unity-2020-2-for-smoother-gameplay-what-did-it-take/ for recent Unity improvements or https://frankforce.com/frame-rate-delta-buffering/ for a strategy working on a specific game.

I think there are several things of this design decision that are worth revisiting:

1. I'm not aware of any reason why Android should be treated differently from the other backends. Considering the algorithm applied is not particularly good (most smoothing approaches go for a weighted average or some kind of low filter) and in many scenarios the current solution will impact how lag is perceived in games and feel worse than raw delta. I think we should remove the smoothing from Android.
2. The "maybe smoothed" version getDeltaTime() is used across libGDX code base by different systems to get the delta time (with calls to Gdx.graphics.getDeltaTime()). This means that, even if a user didn't want the smoothed delta to be used on his game, some parts of libGDX (from Scene2D to particles among others) would still use the smoothed one causing unpredictable issues.
3. As an larger scoped improvement (that would entail breaking backwards compatibility) I think it's worth evaluating adding optional Delta capping and the ability to provide a Smoothing strategy at framework level. We could also consider having getDeltaTime() to return raw delta time and add a getSmoothedDeltaTime() (Unity has something on these lines).

[MrStahlfelge]

I agree that it doesn't make any sense to have this on Android only, and that the current smoothing algorithm could be improved. I would prefer a simple clamping of the delta time, a common suggestion for libgdx games (related: #6093, but there was also a lot of forum and discord talk on this because such a clamp is needed on desktop if the window is resized).

Given the problem that many internal methods use getDeltaTime(), an approach could be to remove getRawDeltaTime() and add configuration options how getDeltaTime() smoothens the output (raw values, clamp, ...)

[crykn]

Yep, I think we should remove the smoothing in the Android backend and change the javadoc accordingly. It should also be mentioned that clamping may happen (at least on mobile platforms).

Given the problem that many internal methods use getDeltaTime(), an approach could be to remove getRawDeltaTime() and add configuration options how getDeltaTime() smoothens the output (raw values, clamp, ...)

That sounds like a good idea that allows for minimal changes in libGDX.