Closed rumblesan closed 7 years ago
can you point me at the line I'll take a look whether it's stale code
https://github.com/davidedc/livecodelab/blob/master/coffee/core/animation-loop.coffee#L103-121
It's basically all that code. We have the global shim being pulled in, and we never really have a reason not to use requestAnimationFrame and force using timeouts instead.
just feels like code that isn't really needed and could be removed
it is possible that this was experimental code and it's now stale, let me check with a clear head tomorrow
no worries, it's been in there pretty much as long as I can remember heh
oh, yes, you found it, that piece of code "caps" the framerate then, which might be useful to do, as the requestAnimationFrame normally fires "as fast as possible".
There must be a better way to cap the framerate though: by using the timeout and then invoking requestAnimationFrame, rather than how it's done here (using timeouts only).
The advantage of using requestAnimationFrame also in the "capped fps" scenario is that requestAnimationFrame is more efficient and consolidates several repaints together (say, the ones from codemirror and the ones from the canvas(es))...
so just having a look at this again. found this http://creativejs.com/resources/requestanimationframe/ shows almost exactly the technique you thought up @davidedc if we still care about setting the framerate then it would be good to implement
The animation loop still has checks around users forcing timeouts for animation. Given that there's still the requestAnimationFrame shim, so we still need this?