Controlling fps with requestAnimationFrame?
Solution 1
How to throttle requestAnimationFrame to a specific frame rate
Demo throttling at 5 FPS: http://jsfiddle.net/m1erickson/CtsY3/
This method works by testing the elapsed time since executing the last frame loop.
Your drawing code executes only when your specified FPS interval has elapsed.
The first part of the code sets some variables used to calculate elapsed time.
var stop = false;
var frameCount = 0;
var $results = $("#results");
var fps, fpsInterval, startTime, now, then, elapsed;
// initialize the timer variables and start the animation
function startAnimating(fps) {
fpsInterval = 1000 / fps;
then = Date.now();
startTime = then;
animate();
}
And this code is the actual requestAnimationFrame loop which draws at your specified FPS.
// the animation loop calculates time elapsed since the last loop
// and only draws if your specified fps interval is achieved
function animate() {
// request another frame
requestAnimationFrame(animate);
// calc elapsed time since last loop
now = Date.now();
elapsed = now - then;
// if enough time has elapsed, draw the next frame
if (elapsed > fpsInterval) {
// Get ready for next frame by setting then=now, but also adjust for your
// specified fpsInterval not being a multiple of RAF's interval (16.7ms)
then = now - (elapsed % fpsInterval);
// Put your drawing code here
}
}
Solution 2
Update 2016/6
The problem throttling the frame rate is that the screen has a constant update rate, typically 60 FPS.
If we want 24 FPS we will never get the true 24 fps on the screen, we can time it as such but not show it as the monitor can only show synced frames at 15 fps, 30 fps or 60 fps (some monitors also 120 fps).
However, for timing purposes we can calculate and update when possible.
You can build all the logic for controlling the frame-rate by encapsulating calculations and callbacks into an object:
function FpsCtrl(fps, callback) {
var delay = 1000 / fps, // calc. time per frame
time = null, // start time
frame = -1, // frame count
tref; // rAF time reference
function loop(timestamp) {
if (time === null) time = timestamp; // init start time
var seg = Math.floor((timestamp - time) / delay); // calc frame no.
if (seg > frame) { // moved to next frame?
frame = seg; // update
callback({ // callback function
time: timestamp,
frame: frame
})
}
tref = requestAnimationFrame(loop)
}
}
Then add some controller and configuration code:
// play status
this.isPlaying = false;
// set frame-rate
this.frameRate = function(newfps) {
if (!arguments.length) return fps;
fps = newfps;
delay = 1000 / fps;
frame = -1;
time = null;
};
// enable starting/pausing of the object
this.start = function() {
if (!this.isPlaying) {
this.isPlaying = true;
tref = requestAnimationFrame(loop);
}
};
this.pause = function() {
if (this.isPlaying) {
cancelAnimationFrame(tref);
this.isPlaying = false;
time = null;
frame = -1;
}
};
Usage
It becomes very simple - now, all that we have to do is to create an instance by setting callback function and desired frame rate just like this:
var fc = new FpsCtrl(24, function(e) {
// render each frame here
});
Then start (which could be the default behavior if desired):
fc.start();
That's it, all the logic is handled internally.
Demo
var ctx = c.getContext("2d"), pTime = 0, mTime = 0, x = 0;
ctx.font = "20px sans-serif";
// update canvas with some information and animation
var fps = new FpsCtrl(12, function(e) {
ctx.clearRect(0, 0, c.width, c.height);
ctx.fillText("FPS: " + fps.frameRate() +
" Frame: " + e.frame +
" Time: " + (e.time - pTime).toFixed(1), 4, 30);
pTime = e.time;
var x = (pTime - mTime) * 0.1;
if (x > c.width) mTime = pTime;
ctx.fillRect(x, 50, 10, 10)
})
// start the loop
fps.start();
// UI
bState.onclick = function() {
fps.isPlaying ? fps.pause() : fps.start();
};
sFPS.onchange = function() {
fps.frameRate(+this.value)
};
function FpsCtrl(fps, callback) {
var delay = 1000 / fps,
time = null,
frame = -1,
tref;
function loop(timestamp) {
if (time === null) time = timestamp;
var seg = Math.floor((timestamp - time) / delay);
if (seg > frame) {
frame = seg;
callback({
time: timestamp,
frame: frame
})
}
tref = requestAnimationFrame(loop)
}
this.isPlaying = false;
this.frameRate = function(newfps) {
if (!arguments.length) return fps;
fps = newfps;
delay = 1000 / fps;
frame = -1;
time = null;
};
this.start = function() {
if (!this.isPlaying) {
this.isPlaying = true;
tref = requestAnimationFrame(loop);
}
};
this.pause = function() {
if (this.isPlaying) {
cancelAnimationFrame(tref);
this.isPlaying = false;
time = null;
frame = -1;
}
};
}
body {font:16px sans-serif}
<label>Framerate: <select id=sFPS>
<option>12</option>
<option>15</option>
<option>24</option>
<option>25</option>
<option>29.97</option>
<option>30</option>
<option>60</option>
</select></label><br>
<canvas id=c height=60></canvas><br>
<button id=bState>Start/Stop</button>
Old answer
The main purpose of requestAnimationFrame
is to sync updates to the monitor's refresh rate. This will require you to animate at the FPS of the monitor or a factor of it (ie. 60, 30, 15 FPS for a typical refresh rate @ 60 Hz).
If you want a more arbitrary FPS then there is no point using rAF as the frame rate will never match the monitor's update frequency anyways (just a frame here and there) which simply cannot give you a smooth animation (as with all frame re-timings) and you can might as well use setTimeout
or setInterval
instead.
This is also a well known problem in the professional video industry when you want to playback a video at a different FPS then the device showing it refresh at. Many techniques has been used such as frame blending and complex re-timing re-building intermediate frames based on motion vectors, but with canvas these techniques are not available and the result will always be jerky video.
var FPS = 24; /// "silver screen"
var isPlaying = true;
function loop() {
if (isPlaying) setTimeout(loop, 1000 / FPS);
... code for frame here
}
The reason why we place setTimeout
first (and why some place rAF
first when a poly-fill is used) is that this will be more accurate as the setTimeout
will queue an event immediately when the loop starts so that no matter how much time the remaining code will use (provided it doesn't exceed the timeout interval) the next call will be at the interval it represents (for pure rAF this is not essential as rAF will try to jump onto the next frame in any case).
Also worth to note that placing it first will also risk calls stacking up as with setInterval
. setInterval
may be slightly more accurate for this use.
And you can use setInterval
instead outside the loop to do the same.
var FPS = 29.97; /// NTSC
var rememberMe = setInterval(loop, 1000 / FPS);
function loop() {
... code for frame here
}
And to stop the loop:
clearInterval(rememberMe);
In order to reduce frame rate when the tab gets blurred you can add a factor like this:
var isFocus = 1;
var FPS = 25;
function loop() {
setTimeout(loop, 1000 / (isFocus * FPS)); /// note the change here
... code for frame here
}
window.onblur = function() {
isFocus = 0.5; /// reduce FPS to half
}
window.onfocus = function() {
isFocus = 1; /// full FPS
}
This way you can reduce the FPS to 1/4 etc.
Solution 3
I suggest wrapping your call to requestAnimationFrame
in a setTimeout
:
const fps = 25;
function animate() {
// perform some animation task here
setTimeout(() => {
requestAnimationFrame(animate);
}, 1000 / fps);
}
animate();
You need to call requestAnimationFrame
from within setTimeout
, rather than the other way around, because requestAnimationFrame
schedules your function to run right before the next repaint, and if you delay your update further using setTimeout
you will have missed that time window. However, doing the reverse is sound, since you’re simply waiting a period of time before making the request.
Solution 4
These are all good ideas in theory, until you go deep. The problem is you can't throttle an RAF without de-synchronizing it, defeating it's very purpose for existing. So you let it run at full-speed, and update your data in a separate loop, or even a separate thread!
Yes, I said it. You can do multi-threaded JavaScript in the browser!
There are two methods I know that work extremely well without jank, using far less juice and creating less heat. Accurate human-scale timing and machine efficiency are the net result.
Apologies if this is a little wordy, but here goes...
Method 1: Update data via setInterval, and graphics via RAF.
Use a separate setInterval for updating translation and rotation values, physics, collisions, etc. Keep those values in an object for each animated element. Assign the transform string to a variable in the object each setInterval 'frame'. Keep these objects in an array. Set your interval to your desired fps in ms: ms=(1000/fps). This keeps a steady clock that allows the same fps on any device, regardless of RAF speed. Do not assign the transforms to the elements here!
In a requestAnimationFrame loop, iterate through your array with an old-school for loop-- do not use the newer forms here, they are slow!
for(var i=0; i<sprite.length-1; i++){ rafUpdate(sprite[i]); }
In your rafUpdate function, get the transform string from your js object in the array, and its elements id. You should already have your 'sprite' elements attached to a variable or easily accessible through other means so you don't lose time 'get'-ing them in the RAF. Keeping them in an object named after their html id's works pretty good. Set that part up before it even goes into your SI or RAF.
Use the RAF to update your transforms only, use only 3D transforms (even for 2d), and set css "will-change: transform;" on elements that will change. This keeps your transforms synced to the native refresh rate as much as possible, kicks in the GPU, and tells the browser where to concentrate most.
So you should have something like this pseudocode...
// refs to elements to be transformed, kept in an array
var element = [
mario: document.getElementById('mario'),
luigi: document.getElementById('luigi')
//...etc.
]
var sprite = [ // read/write this with SI. read-only from RAF
mario: { id: mario ....physics data, id, and updated transform string (from SI) here },
luigi: { id: luigi .....same }
//...and so forth
] // also kept in an array (for efficient iteration)
//update one sprite js object
//data manipulation, CPU tasks for each sprite object
//(physics, collisions, and transform-string updates here.)
//pass the object (by reference).
var SIupdate = function(object){
// get pos/rot and update with movement
object.pos.x += object.mov.pos.x; // example, motion along x axis
// and so on for y and z movement
// and xyz rotational motion, scripted scaling etc
// build transform string ie
object.transform =
'translate3d('+
object.pos.x+','+
object.pos.y+','+
object.pos.z+
') '+
// assign rotations, order depends on purpose and set-up.
'rotationZ('+object.rot.z+') '+
'rotationY('+object.rot.y+') '+
'rotationX('+object.rot.x+') '+
'scale3d('.... if desired
; //...etc. include
}
var fps = 30; //desired controlled frame-rate
// CPU TASKS - SI psuedo-frame data manipulation
setInterval(function(){
// update each objects data
for(var i=0; i<sprite.length-1; i++){ SIupdate(sprite[i]); }
},1000/fps); // note ms = 1000/fps
// GPU TASKS - RAF callback, real frame graphics updates only
var rAf = function(){
// update each objects graphics
for(var i=0; i<sprite.length-1; i++){ rAF.update(sprite[i]) }
window.requestAnimationFrame(rAF); // loop
}
// assign new transform to sprite's element, only if it's transform has changed.
rAF.update = function(object){
if(object.old_transform !== object.transform){
element[object.id].style.transform = transform;
object.old_transform = object.transform;
}
}
window.requestAnimationFrame(rAF); // begin RAF
This keeps your updates to the data objects and transform strings synced to desired 'frame' rate in the SI, and the actual transform assignments in the RAF synced to GPU refresh rate. So the actual graphics updates are only in the RAF, but the changes to the data, and building the transform string are in the SI, thus no jankies but 'time' flows at desired frame-rate.
Flow:
[setup js sprite objects and html element object references]
[setup RAF and SI single-object update functions]
[start SI at percieved/ideal frame-rate]
[iterate through js objects, update data transform string for each]
[loop back to SI]
[start RAF loop]
[iterate through js objects, read object's transform string and assign it to it's html element]
[loop back to RAF]
Method 2. Put the SI in a web-worker. This one is FAAAST and smooth!
Same as method 1, but put the SI in web-worker. It'll run on a totally separate thread then, leaving the page to deal only with the RAF and UI. Pass the sprite array back and forth as a 'transferable object'. This is buko fast. It does not take time to clone or serialize, but it's not like passing by reference in that the reference from the other side is destroyed, so you will need to have both sides pass to the other side, and only update them when present, sort of like passing a note back and forth with your girlfriend in high-school.
Only one can read and write at a time. This is fine so long as they check if it's not undefined to avoid an error. The RAF is FAST and will kick it back immediately, then go through a bunch of GPU frames just checking if it's been sent back yet. The SI in the web-worker will have the sprite array most of the time, and will update positional, movement and physics data, as well as creating the new transform string, then pass it back to the RAF in the page.
This is the fastest way I know to animate elements via script. The two functions will be running as two separate programs, on two separate threads, taking advantage of multi-core CPU's in a way that a single js script does not. Multi-threaded javascript animation.
And it will do so smoothly without jank, but at the actual specified frame-rate, with very little divergence.
Result:
Either of these two methods will ensure your script will run at the same speed on any PC, phone, tablet, etc (within the capabilities of the device and the browser, of course).
Solution 5
How to easily throttle to a specific FPS:
// timestamps are ms passed since document creation.
// lastTimestamp can be initialized to 0, if main loop is executed immediately
var lastTimestamp = 0,
maxFPS = 30,
timestep = 1000 / maxFPS; // ms for each frame
function main(timestamp) {
window.requestAnimationFrame(main);
// skip if timestep ms hasn't passed since last frame
if (timestamp - lastTimestamp < timestep) return;
lastTimestamp = timestamp;
// draw frame here
}
window.requestAnimationFrame(main);
Source: A Detailed Explanation of JavaScript Game Loops and Timing by Isaac Sukin
Related videos on Youtube
robert.vinluan
Updated on March 24, 2022Comments
-
robert.vinluan about 2 years
It seems like
requestAnimationFrame
is the de facto way to animate things now. It worked pretty well for me for the most part, but right now I'm trying to do some canvas animations and I was wondering: Is there any way to make sure it runs at a certain fps? I understand that the purpose of rAF is for consistently smooth animations, and I might run the risk of making my animation choppy, but right now it seems to run at drastically different speeds pretty arbitrarily, and I'm wondering if there's a way to combat that somehow.I'd use
setInterval
but I want the optimizations that rAF offers (especially automatically stopping when the tab is in focus).In case someone wants to look at my code, it's pretty much:
animateFlash: function() { ctx_fg.clearRect(0,0,canvasWidth,canvasHeight); ctx_fg.fillStyle = 'rgba(177,39,116,1)'; ctx_fg.strokeStyle = 'none'; ctx_fg.beginPath(); for(var i in nodes) { nodes[i].drawFlash(); } ctx_fg.fill(); ctx_fg.closePath(); var instance = this; var rafID = requestAnimationFrame(function(){ instance.animateFlash(); }) var unfinishedNodes = nodes.filter(function(elem){ return elem.timer < timerMax; }); if(unfinishedNodes.length === 0) { console.log("done"); cancelAnimationFrame(rafID); instance.animate(); } }
Where Node.drawFlash() is just some code that determines radius based off a counter variable and then draws a circle.
-
maxdec over 10 yearsDoes your animation lag? I think the biggest advantage of
requestAnimationFrame
is (as the name kind of suggests) to request an animation frame only when it is needed. Let's say you show a static black canvas, you should get 0 fps because no new frame is needed. But if you're displaying an animation that requires 60fps, you should get that too.rAF
just allows to "skip" useless frames and then save CPU. -
ViliusL over 10 yearssetInterval do not work in inactive tab too.
-
manthrax over 4 yearsThis code runs differently on 90hz display vs 60hz display vs 144hz display.
-
-
sidonaldson almost 10 yearsIn some instances you are not trying to match the monitors frame rate but rather, in image sequences for example, drop frames. Excellent explanation btw
-
Dean Radcliffe almost 10 yearsNice demo - it should be accepted. Here, forked your fiddle, to demonstrate using window.performance.now() instead of Date.now(). This goes nicely with the high-res timestamp that rAF already recieves, so there's no need to call Date.now() inside the callback: jsfiddle.net/chicagogrooves/nRpVD/2
-
markE almost 10 yearsThanks for the updated link using the new rAF timestamp feature. The new rAF timestamp adds useful infrastruction and it's also more precise than Date.now.
-
Chris Dolphin almost 10 yearsOne of the biggest reasons to throttle with requestAnimationFrame would be to line up execution of some code with the browsers's animation frame. Things end up running a lot smoother, especially if you're running some logic on data every frame, like with music visualizers for example.
-
tavnab almost 9 yearsThis is a really nice demo, which inspired me to make my own (JSFiddle). The main differences are using rAF (like Dean's demo) instead of Date, adding controls to dynamically adjust target framerate, sampling framerate on a separate interval from the animation, and adding a graph of historical framerates.
-
vsync over 8 yearsThis is bad because the main use of
requestAnimationFrame
is to synchronize DOM operations (read/write) so not using it will hurt performance when accessing the DOM, since operations will not be queued to be performed together and will force layout repaint needlessly. -
dronus over 8 yearsThere is no risk of "calls stacking up", as JavaScript runs single threaded, and no timeout event is triggered while the your code is running. So if the function takes longer than the timeout, it just runs almost any time as fast as it can, while the browser would still do redraws and trigger other timeouts inbetween the calls.
-
phocks over 6 yearsThis actually seems to work in keeping the framerate down and so not cooking my CPU. And it's so simple. Cheers!
-
Travis J over 6 yearsI know that you state the page refresh cannot be updated faster than the fps limit on the display. However, is it possible to refresh faster by triggering a page reflow? Conversely, is it possible to not notice multiple page reflows if they are done faster than the native fps rate?
-
jdmayfield over 6 yearsThis is an ingenious solution-- the only problem is it creates additional overhead in the RAF, and can hurt the actual frame-rate due to all the data-manipulation going on inside the RAF. To circumvent this, keep the data manipulation in a seperate setInterval, if possible in a web-worker so it has it's own thread. Ideally the RAF should only update graphics, and read js objects containing current data. Data manipulation should be done outside the RAF and the new data placed in objects for your RAF callback to read.
-
jdmayfield over 6 yearsAs a side note-- in Method 1, if there is too much activity in your setInterval it may slow down your RAF due to single-threaded async. You can mitigate this breaking up that activity over more than on SI frame, so async will pass control back to RAF quicker. Remember, RAF goes at max frame-rate, but syncs graphical changes with the display, so it's ok to skip a few RAF frames-- as long as you don't skip more than SI frames it won't jank.
-
jdmayfield over 6 yearsMethod 2 is more robust, as it is actually multi-tasking the two loops, not switching back and forth through async, but you still want to avoid your SI frame taking longer than your desired frame-rate, so splitting SI activity may still be desirable if it has a lot of data-manipulation going on that would take more than one SI frame to complete.
-
jdmayfield over 6 yearsThis is a nice, simple way to do it for lightweight animations. It does get a little out of sync though, at least on some devices. I used this technique on one of my former engines. It worked good till things got complex. Biggest problem was when hooked up to orientation sensors, it would either lag behind or get jumpy. Later I found using a seperate setInterval and communicating updates between sensors, setInterval frames, and RAF frames via object properties allowed the sensors and RAF to go real-time, while animation time could be controlled via property updates from setInterval.
-
TOPKAT over 6 yearsBest answer ! Thanks ;)
-
jdmayfield over 6 yearsI thought it worth mentioning, as a note of interest, that running paired loops like this actually registers in Chromes DevTools that the GPU is running at the frame-rate specified in the setInterval loop! It appears only RAF frames in which graphical changes occur are counted as frames by the FPS meter. So RAF frames in which only non-graphical work, or even just blank loops, don't count as far as the GPU is concerned. I find this interesting as a starting point for further research.
-
ElJackiste almost 6 yearsCan someone explain me the elapsed % fpsInterval part ? Why we need to "also adjust for your specified fpsInterval not being a multiple of RAF's interval (16.7ms)" ?
-
Curtis over 5 yearsThis will run too fast if your monitor is 120 fps.
-
Curtis over 5 yearsIf my monitor runs at 60 FPS and I want my game to run at 58 FPS I set maxFPS=58, this will make it run at 30 FPS because it will skip every 2nd frame.
-
Curtis over 5 yearsMy monitor is 60 FPS, if I set var fps=60, I only get about 50 FPS using this code. I want to slow it to 60 because some people have 120 FPS monitors, but I don't want to affect everyone else. This is surprisingly difficult.
-
Curtis over 5 yearsAll you can control is when you're going to skip a frame. A 60 fps monitor always draws at 16ms intervals. For example if you want your game to run at 50fps, you want to skip every 6th frame. You check if 20ms (1000/50) has elapsed, and it hasn't (only 16ms has elapsed) so you skip a frame, then the next frame 32ms has elapsed since you drew, so you draw and reset. But then you'll skip half the frames and run at 30fps. So when you reset you remember you waited 12ms too long last time. So next frame another 16ms passes but you count it as 16+12=28ms so you draw again and you waited 8ms too long
-
Edward Torvalds over 5 yearsThis answer does not work for many fps values I tried, 5, 10, 20, 30...
-
MirrorMirror over 5 yearsshouldn't
requestAnimationFrame(animate);
be after theif (elapsed > fpsInterval) {}
block ? -
jdmayfield over 5 yearsYes, I tried this one as well. I choose not to actually throttle the RAF itself-- only the changes are updated by the setTimeout. In Chrome at least, this causes the effective fps to run at the setTimeouts pace, according to readings in DevTools. Of course it can only update real video frames at the speed of the video card and monitor refresh rate, but this method appears to operate with the least jankies, so smoothest "apparent" fps control, which is what I'm going for.
-
jdmayfield over 5 yearsSince I keep track of all motion in JS objects separately from the RAF, this keeps the animation logic, collision detection or whatever you need, running at a perceptually consistent rate, regardless of the RAF or the setTimeout, with a little extra math.
-
pdepmcp about 5 yearsThe reason why you get lower FPS than expected is because setTimeout can execute the callback after more than the specified delay. There is a number of possible reason for this. And every loop it takes the time to set a new timer and execute some code before setting the new timeout. You have no way to be accurate with this, you should always consider a slower than expected result, but as long as you don't know how much slower it will be, trying to lower the delay would be inaccurate as well. JS in browsers is not meant to be so accurate.
-
N4ppeL almost 5 years@MirrorMirror no, that doesn't really matter. RAF only tells the browser to call animate() before it draws the next frame. The only difference in putting it afterwards is that you could miss a RAF call because your code inbetween took longer than the browsers (monitors) frame rate. see also: stackoverflow.com/questions/29181253/…
-
N4ppeL almost 5 yearsI believe this solution has the problem that it keeps running when rAF gets suspended, e.g. because the user switched to another tab.
-
N4ppeL almost 5 yearsP.S. I did some reading and it seems most browsers limit timed events to once per second in background tabs anyway (which should probably also be handled in some way). If you still want to address the issue and completely pause when not visible, there seems to be the
visibilitychange
event. -
jdmayfield almost 5 yearsNice! Yes, they do limit tabs in BG for good reasons! RAF basically just stops. Did not know about visibilitychange event. That would make it much simpler to pause and/or calculate where things should be once the tab is active again!
-
jaysmith024 over 4 yearsThe above solution/answer by @markE has a problem, leave the browser open at 60FPS, let it run. After about 500secs, frame rate drops to 35, then 20's, then down to 13 fps after an hour or so. What is the problem? How can it be fixed?
-
manthrax over 4 yearsThis is broken. There is no accumulation of the remaining time across frames. This render loop is subject to time drift. To fix it, you need to keep track of the time remaining after the modulus, and carry it across to the next frame.
-
dolanator about 4 years@jdmayfield Maybe I'm missing something. I thought you can't change the DOM through a web worker.
-
jdmayfield about 4 yearsYou don't. You do calculations in the web-worker and message the results. Other than that you're still running your RAF the same. You could similarly run another thread via an iframe. The messaging works basically the same. I haven't tried the iframe idea. Either way it would place the calculations in a separate thread than the parts running the RAF and the interval frames.
-
Fuzzy Analysis about 4 yearsPlease add a few sentences to explain what your code is doing, so you can get more upvotes for your answer.
-
Littlee over 3 yearsholy shit,
elapsed > fpsInterval
is much slower thanelapsed > parseInt(fpsInterval)
-
spacorum over 3 yearsThis is the only solution that worked for me on three.js v106
-
Synexis almost 3 yearsAs @manthrax mentioned this may cause drifting. Another fix would be to just increment an "expected" time by the known interval and then wait for it. Also, the first (and only) callback parameter to requestAnimationFrame is a
DOMHighResTimeStamp
(ms but float value, may be more precise in certain builds/circumstances, but regardless cuts the need to call Date,(i.e.,function animate(animationTime) { ... }
) -
Mehdi Dehghani over 2 years@DeanRadcliffe what is
newtime
? I didn't understand the source of it -
R. Navega over 2 years
for(var i=0; i<sprite.length-1; i++)
Why are you using "less-than" with "length-1"? You will never update the last element this way. -
Admin over 2 yearsis it even stable?
-
RhinoDevel over 2 yearsIn response to @manthrax and Synexis comments this may be a good example: cleverti.com/blog/…
-
aggregate1166877 over 2 yearsThis causes significant stutter and shouldn't be used in any production games
-
aggregate1166877 over 2 yearssetTimeout causes significant stutter and shouldn't be used in production games.
-
Kaiido about 2 yearsWhile you will have FPS frames per seconds, each frame won't have the expected duration. When we say we want a 24FPS animation, we actually want each frame to last ~41.7ms, not that we have 23 1ms frames and one 977ms frame (to make things obviously extreme). That's basically what your code is doing, some frames will last 50ms (3 * 16.7), some 33ms (2 * 16.7) but none will have the expected 42ms duration. jsfiddle.net/qtj7mze0
-
Kaiido about 2 years(also regarding the refresh-rate detector, monitors come with funny refresh-rates and any parallel task will get it off. In Chromium you could use a Worker to try to avoid that since rAF is available there, but even then it's rather luck based).
-
fuweichin about 2 yearsIf the
animationFrameRate
detection is slightly off, everything else would be too. To increase animationFrameRate detection accuracy, one way is to callrequestIdleCallback
beforedetectAnimationFrameRate
, and / or pass a larger numIntervals (6 by default) to detectAnimationFrameRate, but still, it depends. -
vanowm about 2 yearsOne caveat though, it doesn't display current FPS, it displays average fps since the start. If you set a higher fps limit, it will start slowing down the more time passes.