3 ms·

requestAnimationFrame is much better here. If you're just drawing into a canvas, there's no reason to do that every N milliseconds - you want to do it once per

requestAnimationFrame is much better here. If you're just drawing into a canvas, there's no reason to do that every N milliseconds - you want to do it once per screen refresh, which is what RAF is for. There's also the added benefit that RAF won't fire when the document isn't visible, so you don't waste cycles drawing to a canvas that's in a background tab, etc.

tomxor 5y ago
> there's no reason to do that every N milliseconds Usually if you want to do any kind of posteriori procedural animation i.e real-time physics, you need a constant interval, and RAF does not give you this... RAF usually runs at 60FPS but it can drop to 30 or increase to 120 depending on the browser, hardware and power saving modes - Which means whatever you are running in that function can get called at drastically different intervals for different users. In this case the animation is a priori, meaning we don't have to simulate intermediate steps, so it's possible to correct for this inside the RAF alone by using Date.now() as the time parameter for shifting the sine wave... however this is not always the case. And in those cases setInterval can be far simpler when timing is important, but if you want to continue using RAF ultimately you would need to decouple rendering from "physics" or any timing related code that cannot be calculated a priori, and run the latter at a constant interval.
- fenomas 5y ago
  I think a few topics are conflated here. The part of the code that draws pixels into a canvas (or tells webgl to draw) should always be called from RAF - there's never a reason to do that more often than the screen refreshes. And since TFA does basically nothing except set canvas pixels, RAF is clearly the thing to use. OTOH whether you want your animation to advance in real time is a separate issue, regardless of whether the animation is interpolated. If you do want real-time animations, and you're using an interpolated physics engine or similar, there really aren't any good options besides decoupling the interpolation from the rendering. And if you've done that, then it doesn't matter much whether the interpolation is called from RAF or setInterval (personally I use both, so that physics ticks can happen between RAF events if the CPU load is heavy). But as a footnote, setInterval definitely does not give you a "constant" interval. Besides the normal variance, browsers will throttle the events (e.g. if the document is in a background tab).
  - tomxor 5y ago
    Nothing gives you a constant interval, but it attempts to unlike RAF.
beebeepka 5y ago
Reading comprehension, what is it? Did I word my thoughts incorrectly? I did say fallback
- fenomas 5y ago
  I understand that, but the answer is the same. setTimeout isn't needed as a fallback (since RAF is widely supported), and it's not better time-wise (since the code we're talking shouldn't run when the document isn't visible). And to answer the edit, setTimeout is not more reliable than setInterval. They both fire from the same event loop, so timing-wise they're identical (apart from one recurring and the other not).
  - beebeepka 5y ago
    I see. You are downvoting me because you think RAF is only useful for drawing graphics in the active tab, and nothing else. setTimeout is absolutely more reliable than setInterval. Maybe try writing a scheduler/task runner and try for yourself before coming down on people.
    - fenomas 5y ago
      (a) I didn't downvote you. (b) setInterval and setTimeout fire off the same event loop; they can only occur at the same fixed times. Why do you think one is more reliable? Just repeating that it's the case doesn't convey any information. (c) I've written various schedulers; the most recent one is `micro-game-shell` on github if you're interested.
      - beebeepka 5y ago
        b) I've observed different time deltas between the two on embedded and standard PC hardware. That's why I think there's a difference. Also, their behaviour has changed over the last few years, making them extremely unreliable as the user changes tabs

tomxor 5y ago

> there's no reason to do that every N milliseconds Usually if you want to do any kind of posteriori procedural animation i.e real-time physics, you need a constant interval, and RAF does not give you this... RAF usually runs at 60FPS but it can drop to 30 or increase to 120 depending on the browser, hardware and power saving modes - Which means whatever you are running in that function can get called at drastically different intervals for different users. In this case the animation is a priori, meaning we don't have to simulate intermediate steps, so it's possible to correct for this inside the RAF alone by using Date.now() as the time parameter for shifting the sine wave... however this is not always the case. And in those cases setInterval can be far simpler when timing is important, but if you want to continue using RAF ultimately you would need to decouple rendering from "physics" or any timing related code that cannot be calculated a priori, and run the latter at a constant interval.

fenomas 5y ago
I think a few topics are conflated here. The part of the code that draws pixels into a canvas (or tells webgl to draw) should always be called from RAF - there's never a reason to do that more often than the screen refreshes. And since TFA does basically nothing except set canvas pixels, RAF is clearly the thing to use. OTOH whether you want your animation to advance in real time is a separate issue, regardless of whether the animation is interpolated. If you do want real-time animations, and you're using an interpolated physics engine or similar, there really aren't any good options besides decoupling the interpolation from the rendering. And if you've done that, then it doesn't matter much whether the interpolation is called from RAF or setInterval (personally I use both, so that physics ticks can happen between RAF events if the CPU load is heavy). But as a footnote, setInterval definitely does not give you a "constant" interval. Besides the normal variance, browsers will throttle the events (e.g. if the document is in a background tab).
- tomxor 5y ago
  Nothing gives you a constant interval, but it attempts to unlike RAF.

beebeepka 5y ago

Reading comprehension, what is it? Did I word my thoughts incorrectly? I did say fallback

fenomas 5y ago
I understand that, but the answer is the same. setTimeout isn't needed as a fallback (since RAF is widely supported), and it's not better time-wise (since the code we're talking shouldn't run when the document isn't visible). And to answer the edit, setTimeout is not more reliable than setInterval. They both fire from the same event loop, so timing-wise they're identical (apart from one recurring and the other not).
- beebeepka 5y ago
  I see. You are downvoting me because you think RAF is only useful for drawing graphics in the active tab, and nothing else. setTimeout is absolutely more reliable than setInterval. Maybe try writing a scheduler/task runner and try for yourself before coming down on people.
  - fenomas 5y ago
    (a) I didn't downvote you. (b) setInterval and setTimeout fire off the same event loop; they can only occur at the same fixed times. Why do you think one is more reliable? Just repeating that it's the case doesn't convey any information. (c) I've written various schedulers; the most recent one is `micro-game-shell` on github if you're interested.
    - beebeepka 5y ago
      b) I've observed different time deltas between the two on embedded and standard PC hardware. That's why I think there's a difference. Also, their behaviour has changed over the last few years, making them extremely unreliable as the user changes tabs