How do you create a smooth Canvas 2D loop with requestAnimationFrame?
Tests render pipeline timing. Outline: queue rAF per refresh; derive delta from timestamp for frame-rate independence; recurse each frame; cancel via cancelAnimationFrame. Red flag: claiming rAF locks 60fps, ignoring timestamp, or setInterval is fine.
What's really being asked
Whether you understand the browser rendering pipeline and can reason about frame pacing, refresh rate alignment, and frame-rate independent animation logic. Interviewers want to see that you know requestAnimationFrame is not just a timer replacement but a contract with the compositor.
A GOOD ANSWER COVERS four things in order. First, scheduling: you call requestAnimationFrame and pass a callback that the browser will invoke before the next repaint, which aligns with the display refresh rate. Second, timing: you use the timestamp argument, a DOMHighResTimeStamp representing the end time of the previous frame, to calculate delta time in milliseconds so your animation advances at a consistent speed regardless of whether the monitor is 60 Hz, 120 Hz, or 144 Hz. Third, loop structure: because requestAnimationFrame is one-shot, the callback must recursively call requestAnimationFrame again to animate the next frame, and you must store the returned request ID so you can pass it to cancelAnimationFrame when pausing, stopping, or unmounting the component. Fourth, browser behavior: you note that callbacks are paused in background tabs or hidden iframes to save battery, which is a feature, not a bug.
COMMON WRONG ANSWERS include claiming that requestAnimationFrame guarantees 60 frames per second, which ignores modern high refresh rate displays. Another red flag is ignoring the timestamp argument and instead moving objects by a fixed pixel amount per frame, which makes the animation run faster on 120 Hz or 144 Hz monitors. Saying that setInterval or setTimeout are acceptable for Canvas animation is also wrong because they fire independently of the display refresh cycle, causing missed frames, unnecessary work, and tearing.
What usually comes next
How would you handle a tab coming back to the foreground after being hidden, given that timestamps may produce a large delta? How do you throttle or cap delta time to prevent physics explosions after a lag spike? What changes if you move this logic to an OffscreenCanvas inside a worker? How would you synchronize multiple canvases or DOM elements using the shared timestamp?
A concrete example
A particle moving at 200 pixels per second. Inside the rAF callback, you compute delta as timestamp minus lastTimestamp, then update position by 200 multiplied by delta divided by 1000. You then draw the particle with Canvas 2D context fillRect, store the current timestamp as lastTimestamp, and call requestAnimationFrame again. To stop, you call cancelAnimationFrame with the ID saved from the original request.
Interview question
In a Canvas 2D animation loop, why should you calculate movement using the timestamp delta rather than a fixed distance per frame?
- a.It guarantees the callback fires at exactly 60 frames per second on all monitors
- b.It keeps the animation speed consistent across 60 Hz, 120 Hz, and 144 Hz displaysCorrect
- c.It prevents requestAnimationFrame from pausing when the tab is backgrounded
- d.It synchronizes the animation callback with the compositor's display refresh cycle
Why? this is the answer
Using the timestamp delta ensures frame-rate independence so animation speed stays consistent across different refresh rates. Option D confuses the timestamp with requestAnimationFrame itself, which already aligns callbacks with the compositor; the timestamp is needed to account for variable time between those aligned callbacks.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #requestanimationframe
- #canvas
- #animation
- #browser-apis
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles