remove requestAnimationFrame polyfill attempt #5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I don't think the polyfill should be here for a number of reasons. Most of the browsers today do support
requestAnimationFramenatively, so in many cases we are safe to assume that the user should have one, and this is not needed. When needed we can ask the user themselves to do it, since it doesn't seem to be the major focus of this library.The polyfill also hurts more than benefit, since it's going to cause unnecessary iterations and hog the cpu, as the frame rate of the computer may vary a lot. Considering a computer has a frame rate of 60fps, it'll have to paint a frame every 1000/60 second but this assumes a next frame is called on the very next iteration of the event loop which is not realistic.
A smarter polyfill which also make amends to the frame rate and how frequently setTimeout is called based on the previous iteration is the one mentioned on Paul Irish's blog post about
requestAnimationFrame.