Lots of seconds get skipped in countdown timer script - javascript

I have made a countdown timer. It uses the date function to get the current time. Then it stores that time in another var. This new var gets changed hours/minutes/seconds, so the format should be the same as the date function.
Then I turn both variables into time since counting, in milliseconds.
Then I substract the current date from the new date thingy, to get the time difference from both variables in milli seconds. This should be the difference from the current time to the target time.
After this, I will turn the difference into a readable hours/minutes/seconds timeformat, which will be displayed in a div. Also added a piece of code for allowing an blinking countdown timer, which will give 5 minutes extra time if the timer has run out. (this countdown timer should be part of a larger script, doing things)
BIG PROBLEM IS: The timer works. Does everything I want it to do. But it's very laggy! It skips displaying seconds, even if I set the setTimeout to 10 ms. I also use a clock using the same timer set-up (different vars), and that clock doesn't skip any time, with a setTimeout of 1000 ms...
Tryed to make some calculations smaller, even read alot about the setTimeout and setInterval drift in javascript, but this doesn't explain my current problems. (using setTimeout for a chat, to reload messages every 500 ms, and that works like a charm so my computer/client/server can handle smaller then 1000 ms times)
Skipping seconds happens on IE and firefox. Other countdown timers (which don't do what I want them to do) also run fine in my browser. What's the problem here?!?
https://jsfiddle.net/77cnvq82/
function startMyFunction() {
setTimeout(myFunction, 100);
}
In this example, the speed has been set to 100ms

The actual issue is in your rounding and math, not in the display code itself.
If you change your display line to:
timerShowRemaining = timerShowRemaining+timerHours+":"+timerMinutes+":"+timerSeconds
+ (new Date());
It will display the current time and you'll see the seconds count up evenly, even as your calculated numbers jerk and lag.

Related

.after don't read the var value

When I use this code even if I change the value of the "seconds" variable, it always starts the "PresaTavOff" function at 1 minute and 20 seconds, even if as a value 50 seconds or 1 second
function doGet() {
var seconds = 10
UrlFetchApp.fetch('https://maker.ifttt.com/trigger/trigger_name_1/with/key/api');
ScriptApp.newTrigger('PresaTavOff')
.timeBased()
.after(seconds*1000)
.create();
}
function PresaTavOff(){
UrlFetchApp.fetch('https://maker.ifttt.com/trigger/trigger_name_2/with/key/api');
}
I also tried:
var seconds = parseInt(10)
The code works and does everything, only the wait that doesn't respect the time I give it.
what am I wrong?
Thanks
There is an open issue for time based trigger could not fire after few seconds, which has been acknowledged by Google and reported internally.
Whilst the documentation specifies that time based triggers are set after x milliseconds my experience is that they never run exactly after the specified time. I've not seen any official documentation on limitations of the .after() method, but Google do say when installing repeating time based triggers the "the time may be slightly randomized".

setInterval timer be more slower when go another chrome tab

I build a countdown timer, so - When I stay in the countdown chrome tab, its work fine.
But when I go to another tab (while the countdown) running, its made it slower.
for example when you start countdown for 30 seconds, and you go to another tab for 10 seconds, when you go back to the countdown tab it will be in 24 seconds - instead of 20 seconds (its just example its very changeable).
stopper = setTimeout(progressCountdown, 1000);
the progressCountdown function its not needed here because its work fine when I in the countdown tab.
There is some option to fix that?
A timeout is not guaranteed to be run after exactly the given delay. In fact, there can be a number of reasons why the delay will be longer than the one you give, for instance if your web page or CPU is overloaded with work, or if it's throttled by the browser to save power and battery (which is what many browsers do with background tabs). MDN has a list with many reasons why these things may occur.
What seems to be your actual problem, however, is that you're using the timeouts to track time itself. This will often be very inaccurate due to the above problems. What you should do instead is to use a clock to keep track of the time spent before the timeout fires:
// performance.now() is a good way of measuring durations
let atStart = performance.now();
function timeoutCallback() {
let now = performance.now();
// milliseconds is accurate now matter how long the timeout actually took
// no matter if in foreground or in background tab
let milliseconds = now - atStart;
// number of seconds left
let secondsLeft = Math.ceil(30 - milliseconds / 1000);
console.log('Countdown: ' + secondsLeft);
if(secondsLeft > 0)
setTimeout(timeoutCallback, 1000);
}
setTimeout(timeoutCallback, 1000);

A counter made in Node.js which changes its value at definite time intervals

I am asking help for a problem which I am not able to solve despite every effort. I am trying to make a counter. This counter is to be placed in a div under the available items on a webpage. This counter should be able to change its value at predefined values and intervals, for example, the value starts at 5,000 at then decreases by 1 after 2 seconds and then by 4 after next 5 seconds and then by 3 after next 2 seconds and then the process repeats (decreases by 1 after 2 seconds...) three or four sets of variation will be enough.
The value shown by the counter must not be affected by the number of page loads or simultaneous users, also it should remain if the user sees the page in two different browsers, it must only be shown as described above.
This counter must be capable of changing its value without needing the user to refresh the page.
Most straightforward solution as it appears to me would be to make the timer relative to absolute time.
This means you take the time passed since an arbitrary point in time you define as the start, e.g. right now which is var start = Date("Thu Jun 04 2015 01:46:44 GMT+0200 (CEST)") here. You can now subtract start from the current time to learn how much time has passed:
var passedSeconds = (new Date() - start) / 1000;
We divide by 1000 since JS calculates with miliseconds by default.
To update the timer, do a simple
setInterval(function() {
var passedSeconds = (new Date() - start) / 1000;
var value = doCalculationForSeconds(passedSeconds);
document.getElementById('myDisplay)'.textContent = value;
}, 1000);
which calls this method every second.
Lastly, you need to figure out a good way to calculate the progress. You could either run your formula in a big loop for all of passedSeconds. Or you evaluate if you can reduce it to a single calculation step. Will depend on the exact changes in value you'll have in your final version.

setInterval slows down with tab/window inactive

I build a web app and I use setInterval with 500ms timer for some clock.
When the window is active the clock runs perfect, I use that:
var tempTimer = 0;
setInterval(function () {
goTimer()
}, 500);
function goTimer() {
tempTimer++;
$("#timer").val(tempTimer);
}
But the problem is when the window/tab becomes inactive - the interval is changed to 1000ms!
When i focus the window/tab again, it changes back to 500ms.
check this out: http://jsfiddle.net/4Jw37/
Thanks a bunch.
Yes, this behavior is intentional.
See the MDN article:
In (Firefox 5.0 / Thunderbird 5.0 / SeaMonkey 2.2) and Chrome 11,
timeouts are clamped to firing no more often than once per second
(1000ms) in inactive tabs; see bug 633421 for more information about
this in Mozilla or crbug.com/66078 for details about this in Chrome.
And the spec says:
Note: This API does not guarantee that timers will run exactly on
schedule. Delays due to CPU load, other tasks, etc, are to be
expected.
You seem to want a timer that increments every half second. You can do that much more accurately by keeping track of the total time since you started and doing some math.
var tempTimer = 0;
var startedTimer = Date.now();
setInterval(goTimer, 250); // a little more often in case of drift
function goTimer() {
tempTimer = Math.floor((Date.now() - startedTimer) / 500);
$("#timer").val(tempTimer);
}
See this work here: http://jsfiddle.net/4Jw37/2/
So this does update every half second, but it doesn't need to. If it skips a few beats it will fix itself the next time it fires because it's recalculating each time based on the time since it started tracking. The number of times the function runs is now has no effect on the value of the counter.
So put in another way, do not ask how many times you incremented the count. Instead ask how many half second segments have passed since you started.
For time interval, Browsers may not behave similar for both active and inactive window.
What you can do, When you are setting the time interval you can save the timestamp(initial time). On window.onfocus, take on there timestamp (now) find the difference between initial time and now and use that update the tempTimer.

Milliseconds out of sync

I am developing a stopwatch application using Javascript/jQuery. The problem is that the milliseconds value is out of sync with REAL milliseconds. I am using function setInterval() with the interval of 1 millisecond, still it is causing this problem.
jsFiddle: http://jsfiddle.net/FLv3s/
Please help!
Use setInterval to trigger updates, but use the system time (via new Date()) for the actual time calculations.
To be honest, I tried nearly the same thing as you do now (Creating an accurate Metronome in Javascript only) - to make a long story short: To be absolutely accurate in terms of milliseconds (or lower) is sadly not (yet) possible with javascript only.
For more insight i recommend this question: Does JavaScript provide a high resolution timer?
or to be more precise this blog article: http://ejohn.org/blog/how-javascript-timers-work/
Best regards,
Dominik
Program execution in any language, not just JavaScript, is not realtime. It will take a tiny amount of time to actually run the code to increment your counter and update the view, and that throws the "timing" off.
Additionally, many browsers have a "minimum timeout" length, which varies between 4 and about 16 (the latter being the computer's own clock timer), which will really mess with your code.
Instead, you should use delta timing.
var startTime = new Date().getTime();
setInterval(function() {
var elapsed = new Date().getTime()-startTime;
// update view according to elapsed time
},25);
If you're worried about it looking choppy, consider using requestAnimationFrame instead, to update the timer exactly once per frame - this has the added benefit of not updating when the user switches tabs (but it will still be timing them) because if the tab is not active then there's no need to redraw stuff.
You can use the new performance object to get a more accurate time. Combine this with requestAnimationFrame instead of setInterval:
var startTime = performance.now(),
currentTime,
isRunning = true;
loop();
function loop(timeElapsed) {
currentTime = performance.now();
if (isRunning) requestAnimationFrame(loop);
}
Just subtract startTime from currentTime.
I left timeElapsed which contains time elapsed handed by rAF which you can may use also for something (or just ignore it).
One note though: not all browsers support this yet (and some may use prefix) so for mobile you need to use the standard system time object.

Categories