Sign in to follow this  
thedupdup

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

Recommended Posts

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? 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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). 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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). 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.