Why is this counter going down when the tab is in the background?

[thedupdup]

I have a counter that subtracts the delta each from and adds the update frequency from the server (at the same frequency) . Here is a simplified version of my code:

 

(function loop(now) {

var now = Date.now();
delta = now - Time;
		
Time = now;
	
timeElapsed -= delta;	

if(frameAvg == null){
frameAvg = delta;
}
frameAvg = (frameAvg + delta) / 2;
	



counter += frameAvg;

if(counter > updateFrequency){
timeElapsed += updateFrequency;
counter -= updateFrequency;	
}

console.log(timeElapsed);

requestAnimationFrame(loop)
			
	})(0);	

When I load the page and take a look at console it is fine, timeElapsed is around 300. But if I switch tabs for a few minutes timeElapsed will then be far into the negative numbers (around -3000 if you leave it for a few minutes). I don't understand what the problem is, how can I fix it? 

[b10b]

Code issues aside, one thing to note is that requestAnimationFrame is usually significantly reduced on a background tab (sometimes not updated at all).  Can you explain your goal (with new words) as there may be a simpler solution.

[thedupdup]

1 hour ago, b10b said:

Code issues aside, one thing to note is that requestAnimationFrame is usually significantly reduced on a background tab (sometimes not updated at all).  Can you explain your goal (with new words) as there may be a simpler solution.

The variable timeElapsed is for a lerp function. I haven't been able to get good results in any other way. I based the lerp function on this: https://gamedev.stackexchange.com/questions/102483/client-interpolation-for-100-serverside-game

[Antriel]

That stackexchange answer is quite close to phase-locked loop I describe here: https://antriel.com/post/online-platformer-5/.

[thedupdup]

2 minutes ago, Antriel said:

That stackexchange answer is quite close to phase-locked loop I describe here: https://antriel.com/post/online-platformer-5/.

Can you explain to me a bit better what a phase locked loop is in this context? 

[b10b]

Yep the stackexchange answer is fine.  Note there are no assumptions that delta will always be < updateFrequency.

[Antriel]

4 minutes ago, thedupdup said:

Can you explain to me a bit better what a phase locked loop is in this context? 

It's a way to have refresh rate of something locked to signals from something else. I use it to sync clients time with server network tick.

[thedupdup]

15 minutes ago, b10b said:

Yep the stackexchange answer is fine.  Note there are no assumptions that delta will always be < updateFrequency.

No, if I do it like the stack exchange example, the timeElapsed will increase a bunch when the tab is not active. And delta will always be smaller then update frequency. 

[thedupdup]

16 minutes ago, Antriel said:

It's a way to have refresh rate of something locked to signals from something else. I use it to sync clients time with server network tick.

The frequency by itself is not the problem, its when i switch tabs the timeElapsed variable decreases a bunch (im not sure what this is caused by). 

[b10b]

45 minutes ago, thedupdup said:

No, if I do it like the stack exchange example, the timeElapsed will increase a bunch when the tab is not active. And delta will always be smaller then update frequency. 

I don't think you should assume anything about delta.  Your code snippet doesn't define updateFrequency so I have to guess what it is, but I can imagine scenarios where delta is quite large.  More to the point 'counter -= updateFrequency' is likely making the assumption that counter is only fractionally larger than updateFrequency, rather than multiples of.  For the latter outcome you might consider using a while loop rather than an if.

[thedupdup]

11 minutes ago, b10b said:

I don't think you should assume anything about delta.  Your code snippet doesn't define updateFrequency so I have to guess what it is, but I can imagine scenarios where delta is quite large.  More to the point 'counter -= updateFrequency' is likely making the assumption that counter is only fractionally larger than updateFrequency, rather than multiples of.  For the latter outcome you might consider using a while loop rather than an if.

The delta average (when the tab is active) is around 16 milliseconds, the updateFrequency has a minimum of 40 milliseconds. I think we are missing the point of the question though: things only go wrong after the tab is inactive for some time. If you just load the page the values are fine, but when you switch tabs the timeElapsed variable is decreased a bunch. So if I loaded the page then switched to a new tab for 3 minutes, timeElapsed would be around -3000, this is not supposed to happen however. 

[b10b]

29 minutes ago, thedupdup said:

I think we are missing the point of the question though: things only go wrong after the tab is inactive for some time.

I get that.  When the tab is inactive requestAnimationFrame effectively pauses, so delta effectively grows.  When it resumes the delta will be the equivalent of all those imagined smaller deltas added together.  Hence timeElapsed returning -3000 (things are happening exactly as coded).  But I actually don't think this is the point ... it is ok to have timeElapsed as -16, -3000, 1,000,000, or 0, just so long as the logic that acts on it considers all possible range (not just the expected range).

[thedupdup]

3 minutes ago, b10b said:

I get that.  When the tab is inactive requestAnimationFrame effectively pauses, so delta effectively grows.  When it resumes the delta will be the equivalent of all those imagined smaller deltas added together.  Hence timeElapsed returning -3000 (things are happening exactly as coded).  But I actually don't think this is the point ... it is ok to have timeElapsed as -16, -3000, 1,000,000, or 0, just so long as the logic that acts on it considers all possible range (not just the expected range).

I see what you mean now. But if I add to timeElapsed like in the stackexchange example timeElapsed seems to increase a bunch (the opposite of what was happening before). 

[b10b]

@thedupdup I'm guessing a little in the dark here ... but perhaps move away from if(counter to while(counter ... there will likely be some knock on effects to consider too ... 

[thedupdup]

1 minute ago, b10b said:

@thedupdup I'm guessing a little in the dark here ... but perhaps move away from if(counter to while(counter ... there will likely be some knock on effects to consider too ... 

What would that do?

[b10b]

1 hour ago, thedupdup said:

What would that do?

It would be a start towards considering the scenarios where counter (derived from delta) is significantly larger than updateFrequency (and therefore not fully resolved with the singular if).  You should next reconsider your assumptions around averages.  I'm going to sign off there as I'm repeating myself.  Good luck.