Allow specifying a different requestAnimationFrame function

[IceCreamYou]

This library currently uses window.requestAnimationFrame if available and falls back to setTimeout otherwise. The upcoming WebVR API will use display.requestAnimationFrame to schedule frames on attached VR displays. This library should support such loops.

[Djedjeska]

Hello, the documentation says that it can be used in Node.js with require('mainloop')
But when I tested, it simply isn't possible because of the use of "window', which obviously isn't available server-side...

[IceCreamYou]

Hello, the documentation says that it can be used in Node.js with require('mainloop')
But when I tested, it simply isn't possible because of the use of "window', which obviously isn't available server-side...

As explained in #21, the comment above is incorrect - in Node.js, MainLoop.js uses a custom fallback for requestAnimationFrame. However, adding the ability to use an alternative requestAnimationFrame function would also allow Node.js users to provide their own fallback instead of the one the library provides.

[dakom]

In terms of the one the library provides, would there be any advantage to scheduling the timeout to use performance? if that is available?

Use case is running the loop in a worker which does not have requestAnimationFrame but does have performance

[IceCreamYou]

In terms of the one the library provides, would there be any advantage to scheduling the timeout to use performance? if that is available?

I don't understand the question. window.performance does not have any scheduling APIs.

[dakom]

Yes but in the fallback, you schedule it via passing Date.now (and an offset) to setTimeout()

Would there be any advantage to using performance.now instead of Date.now ?

[IceCreamYou]

The short answer is no, there wouldn't be a meaningful difference. The long answer is that the differences are:

• performance.now() is slower in microbenchmarks in some browsers but it shouldn't make a meaningful difference to call it once per frame.
• Date.now() can jump around if the system clock changes. In practice this isn't a big deal because it happens rarely and the requestAnimationFrame shim in this library accounts for backward jumps.
• performance.now() was intended to be higher precision, but in practice it is not any more because it was found that high precision timers could be used to exploit CPU cache bugs.
• Date.now() is more portable.