Hype AnimationFrame

This is a Hype AnimationFrame, a wrapper for window.requestAnimationFrame (without polyfill for it). Will keep polyfills from now on separate, so projects that already use them don’t load them twice.


Online Example:

Example Hype File:

1.0 Initial release under MIT
1.1 Converted into a self contained extension
1.2 Added id, scope and refactored names

PPS: Looking forward to these extended symbols so we have unified distribution of this stuff


PS: Fixed the missing parameter missing in the function.apply --> time. Will add an example using time in the next update.

↑ look at project
1.1 Converted into a self contained extension

@jonathan I get some jitter. Is this because the frameAction is firing more often then the VSync?

↑ look at project
1.2 Added id, scope and refactored names

I externalized the library into an .JS-file. There is also a minified version now. Please don’t hotlink in production, for testing it’s okay! If you don’t want an additional file request just dump the content of the minified version into your Head HTML in a <script>...</script> enclosure.

I think I’d need to see a video of the issue; it seems to work fine for me. Sometimes dropped frames look like jitter (moving ahead or behind) due to how our brain works, so it is useful to look in slow-mo to see what is actually happening. Also note:

  • vsync issues would cause tearing; browsers draw double-buffered so practically this cannot happen
  • When a call is under requestAnimationFrame, it will group anything requiring a paint together, so it should all get painted together

I am wondering though what the use case of this is, instead of just using requestAnimationFrame directly?

It stops all loops on scene changes no matter how many you start and takes out the pain of having to understand or think about the break off and self calling in each tick.

1 Like