I'm currently trying to write my own JavaScript library. I'm in the middle of writing an animation callback, but I'm having trouble getting precise end values, especially when animation duration times are smaller.
Right now, I'm only targeting positional animation (left, top, right, bottom). When my animations complete, they end up having an error margin of 5px~ on faster animations, and 0.5px~ on animations 1000+ ms or greater. Here's the bulk of the callback, with notes following.
var current = parseFloat( this[0].style[prop] || 0 )
// If our target value is greater than the current
, gt = !!( value > current )
, delta = ( Math.abs(current - value) / (duration / 13) ) * (gt ? 1 : -1)
, elem = this[0]
, anim = setInterval( function(){
elem.style[prop] = ( current + delta ) + 'px';
current = parseFloat( elem.style[prop] );
if ( gt && current >= value || !gt && current <= value ) clearInterval( anim );
}, 13 );
this[0] and elem both reference the target DOM element.
prop references the property to animate, left, top, bottom, right, etc.
current is the current value of the DOM element's property.
value is the desired value to animate to.
duration is the specified duration (in ms) that the animation should last.
13 is the setInterval delay (which should roughly be the absolute minimal for all browsers).
gt is a var that is true if value exceeds the initial current, else it is false.
How can I resolve the error margin?
You can run into rounding errors that will end up adding up to a different value than you expected. You might take a look at a really simple animation library and see the method they use to overcome this (as well as some easing techniques). Here is Thomas Fuchs' Emile which is about 50 lines of code:
http://github.com/madrobby/emile/blob/master/emile.js
In addition to what Alex says, you're usually better off using time-based calculation rather than trying to make discrete steps. This ensures accuracy and allows the animation to run at a reasonable speed when the browser's not fast enough to reliably call you back every n microseconds.
function animate(element, prop, period, value) {
var v0= parseFloat(element.style[prop] || 0); // assume pre-set in px
var dv= value-v0;
var t0= new Date().getTime();
var anim= setInterval(function() {
var dt= (new Date().getTime()-t0)/period;
if (dt>=1) {
dt= 1;
clearInterval(anim);
}
element.style[prop]= v0+dv*dt+'px';
}, 16);
}
Related
I have the following function that scrolls some elements "up" out of view by adjusting their style every "tick":
const incr = 1;
let moved = 0;
function changeHeight( children, duration, setTop) {
// duration = 1500
const height = children.clientHeight; // in this case, 166px
let moved = 0;
const slideUp = function (timestamp) {
// we're done if the amount moved is larger than height
if ( moved < height ) {
children.style.top = `${ setTop( moved, height ) }px`;
moved = moved + incr // move by some amount
requestAnimationFrame(slideUp)
} else {
// reset
moved = 0;
}
};
// start sliding
slideUp();
}
If requestAnimationFrame triggers roughly every 16ms or so, I would like to use duration to dictate how long the animation will be running for, so the formula seems to be height * 16.5 / duration
I'm confused by requestAnimationFrame - why is the time per tick not constant? I'd like to use timestamp that's generated by requestAnimationFrame but the first few cycles take much longer than the average of ~16.5
Is the 16.5 going to look different on a different machine or screen?
How do I make the height change take exactly the amount of time specified?
What you want is called delta-time.
The formula is Math.min((now - start) / duration, 1) * final_amount.
Using this delta-time, you don't need to care at which frequency your interval fires, every step is rendered "where it should be".
As for your questions,
why is the time per tick not constant
Certainly because the browser has a lot of things to do during the first frames and couldn't do everything in the 16.7ms frame. It will thus move your callback to be executed a bit later, and may even skip frames if under too much pressure.
Is the 16.5 going to look different on a different machine or screen?
Yes, requestAnimationFrame will basically try to follow the monitor's refresh rate. So on a 60Hz monitor you'll indeed have 16.7ms per frame, but on a 120Hz monitor you'd have only half of it.
How do I make the height change take exactly the amount of time specified?
Use a delta-time:
const elem = document.querySelector("div");
let moved = 0;
changeHeight(elem, 200, 5000);
function changeHeight(elem, height, duration) {
const start = performance.now();
const step = function () {
const now = performance.now();
const delta = Math.min((now - start) / duration, 1);
elem.style.height = (delta * height) + "px";
if (delta < 1) {
requestAnimationFrame(step);
}
};
step();
}
div { width: 50px; background: green; }
<div></div>
I have created pretty easy gallery. The elements gets their transform position increased or decreased on click using
function pushIt(max, target, index, count) {
if (count == max ) {
target[index -1].addEventListener("transitionend",turnOf,false);
return;
}
var tmp = target[index];
var matrix = window.getComputedStyle(tmp).getPropertyValue("transform");
var translate_left = matrix.split(",")[4];
var translate_top = matrix.split(",")[5].split(")")[0]-215;
tmp.style.transform = "translate3d(" + translate_left + "px," + translate_top + "px,0)";
setTimeout(function(){
pushIt( max, target, index + 1, count + 1 );
},50)
}
function turnOf(){
running = false;
this.removeEventListener(turnOf);
}
Everything is working fine , but the problem is , when i click xxx time rly fast , it gets destroyed and does unwanted behavior. I am using flag, so the function can be called only when "running" is false , which i return back to false when the transition of the last element that should be moved is over. It works on the first few clicks , but fast clicking ruins it and break whole script.
Live demo ( click rly fast xxx times to see the behavior )
What could cause this? The flag is only set only when the transition ends, so why the function gets invoked ? Is there a way how to fix it , or shoud i use brute force ( promises ) for this?
This seems to be your problem:
function turnOf(){
running = false;
//this.removeEventListener(turnOf);
this.removeEventListener("transitionend", turnOf);
}
I've got this weird problem, I'm incrementing by 1, and yet, the increment that appears when the javascript window pops up, shows that I have incremented either by 9 or 13, the either comes from whether I am incrementing by 1 or -1 respectively. what is up with that?
This the function being called by the requestAnimationFrame
function stream1() {
if (y > origin_y){
var xOffset = -1;
} else if (y == origin_y){
var xOffset = 1;
} else {
var xOffset = 1;
}
var offset = $( "#widget1" ).offset();
var x = offset.left;
var y = offset.top;
console.log(' X - '+x+' Y - '+y);
$( "#widget1" ).offset({ top: y-yOffset, left: xInitial+xOffset });
}
This is the animation frame
var globalID;
function repeatOften() {
stream1();
requestAnimationFrame(repeatOften);
}
It probably doesn't make sense that in the time for the alert to disappear and reappear, 9 iterations have been complete right? It's supposed to be 60 times a second supposedly and it has been like 1 second so shouldn't it be 60 and not 9 or 13? I don't know where these arbitrary numbers come from.
To summarize again, initially xInitial is located at 1114 px, then it goes to 1105 or 1103 and then 9 or 13 gaps subsequentially every time so why is that?
First, avoid expensive operation in frame callback. Like $( "#widget1" ).offset(). Mind that it is DOM operation, it can be slow and broke all timing. You can get DOM id and offset before animation starts and then remember just current offset left and top.
Second, if you want to be super precise, you can use handler urgument, which is timestamp and if you store animation start timestamp you can compute exact position regardless of real frame ratio.
I am looking to create a function that scrolls an image element x pixels over y time on an HTML5 canvas, using requestAnimationFrame and delta time. What I can't figure out is how to add more arguments to my function, when requestAnimationFrame allready calls back my function with one argument (a DOMHighResTimeStamp). I am pretty sure the following code doesn't work:
function scroll(timestamp, distanceToScroll, secondsToScroll) {
//delta = how many milliseconds have passed between this and last draw
if (!lastDraw) {var lastDraw = timestamp;};
delta = (0.5 + (timestamp - lastDraw)) << 0; //bitwise hack for rounding integers
lastDraw = timestamp;
//speed (pixels per millisecond) = amount of pixels to move / length of animation (in milliseconds)
speed = distanceToScroll / secondsToScroll;
//new position = current position + (speed * delta)
position += (speed * delta);
context.drawImage(myImage,0,position,50,50/*of 200*/,0,0,100,100);
requestAnimationFrame(scroll(timestamp, distanceToScroll, secondsToScroll));
};
//later...
scroll(timestamp, 100, 5)
scroll(timestamp, 10, 20)
My question is I have no idea how to force requestAnimationFrame to continute to call my scroll function with my additional parameters, when all it does by default is pass just one argument (a timestamp) on callback. So how do I go about adding more parameters (or forcing rAF to put the timestamp in my 'timestamp' argument)?
What your requestAnimationFrame statement evaluates to:
scroll(timestamp, distanceToScroll, secondsToScroll), where timestamp is undefined. It throws an error or returns undefined
window.requestAnimationFrame is executed without parameters, thus no callback
Passing an anonymous function that calls scroll with the desired parameters should do the trick:
requestAnimationFrame(function(timestamp) {
scroll(timestamp, distanceToScroll, secondsToScroll));
});
What this evaluates to:
window.requestAnimationFrame is called with anonymous function as callback
anonymous function is called with timestamp as first parameter
scroll is called with current timestamp, distanceToScroll and secondsToScroll as parameters
Pure JavaScript
function scrollIntoViewSmooth(elem) {
var move = elem.offsetTop - (elem.offsetTop - elem.parentElement.scrollTop) * 0.25;
if (Math.abs(elem.offsetTop - move) <= 2) {
elem.parentElement.scrollTop = elem.offsetTop;
} else {
elem.parentElement.scrollTop = move;
setTimeout(scrollIntoViewSmooth, 33, elem);
}
}
Example
scrollIntoViewSmooth(document.getElementById('stuff'));
I know a few questions have been asked like this one before, such as this: Check FPS in JS? - which did work to some degree, I was able to find out how long each loop took to complete.
What I am looking for though is something more readable and controllable. I want to be able to set the refresh rate for the FPS counter to make it slow so it is human readable or as fast as the application can run, so I can use it on some kind of speedometer.
Anyway so here is the code I have right now:
var lastLoop = new Date().getTime();
function updateStage()
{
clearCanvas();
updateStageObjects();
drawStageObjects();
var thisLoop = new Date().getTime();
var fps = (thisLoop - lastLoop);
$('#details').html(fps);
lastLoop = thisLoop;
iteration = setTimeout(updateStage, 1);
}
Am I right to be setting the setTimeout function to a speed of 1 millisecond? I was thinking this will just make it loop as fast as it possibly can.
Should I count every 100 frames or so, find out how many milliseconds it took to run 100 frames then make a calculation to find out how many frames it would have done if the milliseconds were 1000? What would this calculation be?
To make the result more accurate I am guessing I need to display averages as one frame can vary a significant amount, how should I do this?
Any tips are greatly appreciated.
Thanks.
Note that the faster you update your output, the more you will affect your measurement. Although minimal, I try to update my fps output once per second or less unless it's necessary to go faster.
I like to have a low-pass filter on my results so that a temporary hiccup doesn't affect the values too strongly. This is easier to compute and write than a moving average, and doesn't have the problem of an overall average where your 'current' readings are affected by total performance over the entire run (e.g. anomalous readings during startup).
Put together, here's how I usually measure FPS:
var fps = 0, now, lastUpdate = (new Date)*1;
// The higher this value, the less the FPS will be affected by quick changes
// Setting this to 1 will show you the FPS of the last sampled frame only
var fpsFilter = 50;
function drawFrame(){
// ... draw the frame ...
var thisFrameFPS = 1000 / ((now=new Date) - lastUpdate);
if (now!=lastUpdate){
fps += (thisFrameFPS - fps) / fpsFilter;
lastUpdate = now;
}
setTimeout( drawFrame, 1 );
}
var fpsOut = document.getElementById('fps');
setInterval(function(){
fpsOut.innerHTML = fps.toFixed(1) + "fps";
}, 1000);
Ive tried something out,
If you change the
lastUpdate = now
to
lastUpdate = now * 1 - 1;
Your NaN problem is solved! This is also used where the lastUpdate is defined. Probably because it is not able to convert the date to unix timestamp.
The new result will be:
var fps = 0, now, lastUpdate = (new Date)*1 - 1;
// The higher this value, the less the FPS will be affected by quick changes
// Setting this to 1 will show you the FPS of the last sampled frame only
var fpsFilter = 50;
function drawFrame(){
// ... draw the frame ...
var thisFrameFPS = 1000 / ((now=new Date) - lastUpdate);
fps += (thisFrameFPS - fps) / fpsFilter;
lastUpdate = now * 1 - 1;
setTimeout( drawFrame, 1 );
}
var fpsOut = document.getElementById('fps');
setInterval(function(){
fpsOut.innerHTML = fps.toFixed(1) + "fps";
}, 1000);
I've taken the solution(s) posted and enhanced them a little. Have a look here - http://jsfiddle.net/ync3S/
I fixed that NaN error by using Date.now() instead of constructing a new date object each time and trying to reference it. This also prevents some garbage collection necessity.
I neatened up the variable and function names a bit and added some extra commenting - not necessary but nice to have.
I included some drawing code for testing.
I added fpsDesired as a test var for the engine loop.
I started fpsAverage at fpsDesired so with the fpsFilter it doesn't work up from 0 to the real FPS, rather starting at the desired FPS and adjusting from there.
Drawing now blocks incase it already was drawing, and this can be used for pausing and other control functions.
The main block is as follows:
var fpsFilter = 1; // the low pass filter to apply to the FPS average
var fpsDesired = 25; // your desired FPS, also works as a max
var fpsAverage = fpsDesired;
var timeCurrent, timeLast = Date.now();
var drawing = false;
function fpsUpdate() {
fpsOutput.innerHTML = fpsAverage.toFixed(2);
}
function frameDraw() {
if(drawing) { return; } else { drawing = true; }
timeCurrent = Date.now();
var fpsThisFrame = 1000 / (timeCurrent - timeLast);
if(timeCurrent > timeLast) {
fpsAverage += (fpsThisFrame - fpsAverage) / fpsFilter;
timeLast = timeCurrent;
}
drawing = false;
}
setInterval(fpsUpdate, 1000);
fpsUpdate();
setInterval(frameDraw, 1000 / fpsDesired);
frameDraw();
Going to have a tinker and see if I can come up with something smoother, as this thread is near the top in Google results.
Let's see what we can all come up with as a team, and I think it's always neat to not use 3rd party libraries, making the code portable for anyone :)
-Platima
Just set a interval that is resetting the fps counter every second.
var fpsOut, fpsCount;
var draw = function () {
fpsCount++;
..Draw To Canvas..
..Get the fps value: fpsOut
requestAnimationFrame(draw);
};
setInterval(function () {
fpsOut = fpsCount;
fpsCount = 0;
}, 1000);
draw();
If you want real-time updates, consider making it loop again and again in real time. To make it affect the performance less, only update the controlled variable, in this case, the FPS. You can have optional Frame Latency, which I will put here, just in case. Just copy, paste and tweak the code to your needs.
Take note that a single frame lasts for 16.66 miliseconds.
setInterval(function(){var latencybase1 = parseFloat(new Date().getTime());
var latencybase2 = parseFloat(new Date().getTime());
var latency = latencybase2-latencybase1;
var fps = Math.round(1000/latency);
if (latency<16.66)
{document.getElementById("FPS").innerHTML = fps+"
FPS";}
else {document.getElementById("FPS").innerHTML = ""+fps+" FPS";}
document.getElementById("Latency").innerHTML = latency+" ms";}, 0);