4 ms·

Instead of `setTimeout` use `requestAnimationFrame` Check out the code of this Lissajous Curve Demo https://ericfortis.github.io/lissajous/ https://ericfortis.

Instead of `setTimeout` use `requestAnimationFrame` Check out the code of this Lissajous Curve Demo https://ericfortis.github.io/lissajous/ https://ericfortis.github.io/lissajous/ This SO answer explains the difference: https://stackoverflow.com/a/38709924/529725 https://stackoverflow.com/a/38709924/529725

zfg 2y ago
MDN Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame https://developer.mozilla.org/en-US/docs/Web/API/Window/requ... Example: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...
noduerme 2y ago
Very cool demo. Sadly, though, the issue here is not in the time taken to request the new frame. I've built the loop to include a delta when each loop promise finishes, so the animation speed (motion across time) is stable. requestAnimationFrame would not help because the throttling is already accounted for; my code changes speed based on the framerate already. The problem is that there's throttling happening in the array manipulation itself. This is why I have a "draw took" and "waited" time (ms) in the upper left: The "draw took" is how long it actually took to render the frame. "waited" is, the code waits the rest of the framerate to start the next frame, so at 60fps (1 framer per 16.6ms) if the frame took 5ms to render, the wait time after rendering would be 11.6ms. What you can see is that "draw took" jumps up for no reason by 10ms after a few seconds of running the code, and then goes back down by 10ms after a minute of running the code. The draw itself - the rewriting of the screen buffer - takes longer because Chrome is throttling something which has nothing to do with the timer function itself. It's throttling something inside the array manipulation.
- zfg 2y ago
  > requestAnimationFrame would not help But have you tried it?
  - noduerme 2y ago
    Yes. The same slowdown of about 50% occurs between about seconds 10 and 50 whether it's in a requestAnimationFrame loop or a setTimeout loop. And the slowdown is measurable in just the time it takes to modify a Uint8ClampedArray within the loop.

zfg 2y ago

MDN Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame https://developer.mozilla.org/en-US/docs/Web/API/Window/requ... Example: https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Basic_animations https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...

noduerme 2y ago

Very cool demo. Sadly, though, the issue here is not in the time taken to request the new frame. I've built the loop to include a delta when each loop promise finishes, so the animation speed (motion across time) is stable. requestAnimationFrame would not help because the throttling is already accounted for; my code changes speed based on the framerate already. The problem is that there's throttling happening in the array manipulation itself. This is why I have a "draw took" and "waited" time (ms) in the upper left: The "draw took" is how long it actually took to render the frame. "waited" is, the code waits the rest of the framerate to start the next frame, so at 60fps (1 framer per 16.6ms) if the frame took 5ms to render, the wait time after rendering would be 11.6ms. What you can see is that "draw took" jumps up for no reason by 10ms after a few seconds of running the code, and then goes back down by 10ms after a minute of running the code. The draw itself - the rewriting of the screen buffer - takes longer because Chrome is throttling something which has nothing to do with the timer function itself. It's throttling something inside the array manipulation.

zfg 2y ago
> requestAnimationFrame would not help But have you tried it?
- noduerme 2y ago
  Yes. The same slowdown of about 50% occurs between about seconds 10 and 50 whether it's in a requestAnimationFrame loop or a setTimeout loop. And the slowdown is measurable in just the time it takes to modify a Uint8ClampedArray within the loop.