Slate Active Timer - InDeltaTime not reliable

Development Programming & Scripting UI
, , ,
1

Hi, I had some problems with an effect running too slow using an Active Timer with Slate.
Instead of finishing in 3 seconds, it took 7 seconds.
Here’s some observations and a workaround, which I want to share, in case someone has similar issues. Maybe someone even has an explanation on what might be going on.

Here we go:

Logging showed, that indeed, using the InDeltaTime seemed to deliver weird results.

The simple code:

EActiveTimerReturnType STest::TimerFunction(double InCurrentTime, float InDeltaTime)
{
	// Just accumulate the InDeltaTimes
	FadeDeltaTime += InDeltaTime;

some snip from log which match my observed behaviour:

[2022.07.30-09.10.04:008][198]LogHerb64: Warning: FadeDeltaTime = 0.460262
....
[2022.07.30-09.10.09:626][198]LogHerb64: Warning: FadeDeltaTime = 2.674903
                  ------                                          --------
                  05:618     < --- mismatch --->                  2.214641

Time delta in the log shows around 5.6 seconds vs. accumulated InDeltaTime values only shows 2.2 seconds. The log timestamps match my observed real time that passed.

My Solution:
Instead of using InDeltaTime, I changed to use InCurrentTime to manually calculate my delta times for accumulation from this one.

The code:

EActiveTimerReturnType STest::TimerFunction(double InCurrentTime, float InDeltaTime)
{
	// For some reason, we cannot rely on InDeltaTime
	if (FadeStartTime == 0.0f)
	{
		FadeStartTime = InCurrentTime;
		FadeDeltaTime = 0.0f;
	}
	else
	{
		FadeDeltaTime = InCurrentTime - FadeStartTime;
	}

log results now match perfectly

[2022.07.30-10.20.06:414][175]LogHerb64: Warning: FadeDeltaTime = 0.394792
...
[2022.07.30-10.20.08:690][175]LogHerb64: Warning: FadeDeltaTime = 2.671123
                  ------                                          --------
                  02:276    < --- perfect match --->              2.276331

Time Delta in Log is the same as the accumulated values, the effect takes 3 seconds as desired.

That’s an interesing thing happening here, I’m not yet sure, what the root cause is. Maybe the timer interval has influence (I registered 0.1s).

Or it is the fact, that this one is running on MoviePlayer (playing with loading screen stuff) - so side effects from multithrading could be a cause as well.

At least I’m happy with this for now until running into the next ‘surprise’ :slight_smile: