I am learning to code in JavaScript. I am programming something with some timed mouse animation. I'm just about to add some code which draws the mouse path.
It's going to be something that takes the mousemove event, and every time the mouse moves draw a new line path on Canvas. And with time, that path is going to be more transparent until it disappears. Of course, new paths are always going to be opaque so there's a continuous movement.
I figured out a way I can do this with just requestanimationframe. Basically every time a new mousemove event occurs, I will add that mouse path coordinates to an array of objects called mousePathArray. The object will carry the path coordinates and an "animationStage" counter. This counter will basically determine how transparent the path will be at that stage of the 'animation'. (Later stages will mean more transparent.)
Then every animation frame I will call a function that will go through all the objects in the array and draw the lines according to their coordinates and animationStage counter, will increase the counter by 1 and will remove the array objects if the animationStage counter reaches the end number (which could be 50 or something).
This can all be done, but it sounds like instead of all of that, it would be much easier to do by just introducing a setInterval function that will be called with a set interval every time the mouse moves.
So is it worth it doing the long way? Would it be faster or maybe just be better JS practice to not use setInterval and rAF together?
After writing all this down I actually wrote the rAF-only code that I talked about above. It's too long to paste here but the rules need it. Here it is on jsfiddle: http://jsfiddle.net/06f7zefn/2/
(I'm aware there are a lot of inefficiencies and probably terrible coding practice but bear with me, I'm 5 days old in this! I could make an isDrawing? boolean instead of calling animate() on every frame, and I can just do ctx.moveTo() once with the rest being LineTo() without having to to moveTo() every iteration since one point originates from where the other left off)
If I could get across the main idea I'm talking about, that is where I am asking for your opinion. Instead of making everything related to timing originate from the rAF call could it be better to use setInterval or setTimeout here instead?
var canvas = document.createElement('canvas');
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
document.body.appendChild(canvas);
var ctx = canvas.getContext('2d');
var currentPosX, currentPosY, prevPosX, prevPosY;
var mousePathArray = [];
canvas.addEventListener ('mousemove', mouseOp);
function mouseOp (mouseEvent) {
prevPosX = currentPosX;
prevPosY = currentPosY;
currentPosX = mouseEvent.clientX;
currentPosY = mouseEvent.clientY;
mousePathArray.push( {
x1: currentPosX,
x2: prevPosX,
y1: currentPosY,
y2: prevPosY,
animStage: 0
});
}
function animate () {
var anims = mousePathArray.length;
if (anims!=0) {
for (i=0; i<anims; i++) {
if (mousePathArray[i].animStage == 20) {
mousePathArray.splice(i, 1);
i--;
anims--;
continue;
}
drawLine(mousePathArray[i].x1, mousePathArray[i].x2, mousePathArray[i].y1, mousePathArray[i].y2, 1 - (mousePathArray[i].animStage * 0.05));
mousePathArray[i].animStage ++;
}
}
}
function drawLine (x1, x2, y1, y2, alpha) {
ctx.beginPath();
ctx.moveTo(x1, y1);
ctx.lineTo(x2, y2);
ctx.strokeStyle = "rgba(150, 20, 150," + alpha +")";
ctx.stroke();
}
animloop();
function animloop(){
window.requestAnimationFrame(animloop);
gameLoop();
}
function gameLoop() {
ctx.clearRect(0, 0, canvas.width, canvas.height);
animate();
}
Luz Caballero does a fair job of describing why rAF is a useful replacement for
setInterval
:https://dev.opera.com/articles/better-performance-with-requestanimationframe/.
As for me, I now use rAF instead of setInterval because rAF has some built-in usefulness that would require additional coding with setInterval:
rAF will attempt to synchronize its calls with the display refresh cycle. This gives the code in the loop the "best chance" to complete between the refresh cycles.
If the tasks in loop#1 can't complete before loop#2 is requested, then the new loop#2 won't be called until the incomplete loop#1 is completed. This means the browser won't be overworked with a backlog of accumulated loops.
If the user switches to a different browser tab then loops in the current tab are suspended. This allows processing power to shift to the new tab instead of being used in the now invisible loop tap. This is also a power-saving feature on battery powered devices. If you want the loop to continue processing while a tab is unfocused you must use setInterval.
The rAF callback function automatically gets a high-precision timestamp argument. This allows rAF loops to calculate & use elapsed times. This elaped time can be used to (1) delay until a specified elapsed time has occurred or (2) "catch up" on time based tasks that were desired but were unable to be completed.