Feature detect to determine RAF timer size

[danro]

@rvagg, was thinking about your feature detect for the window.performance + rAF timers.

If it simplifies things, I would be fine with deferring all morpheus starts until the first frame had passed. Since it's usually <20ms, i'd call it a fair trade for not having to check on each frame.

Most browser-based animation seems to naturally defer at least 200ms anyways. I doubt most use cases would notice a frame difference on dom ready.

Thoughts?

[rvagg]

Yes, I was thinking the same thing, just queue them up and start them all once we've worked it out. It'd make an assumption that rAF actually works in the browser being tested but I suppose that's a safe-enough assumption! The nice thing about starting off with a bare-bones version and then switching it out once we've feature-detected is that if the detection fails for whatever reason we'll still be left with the basic version.

[stereokai]

Was anything done about this feature? Thanks.

[ded]

so far no work has been done on this. surely it wouldn't hurt to move the detection on page load instead of per frame

[stereokai]

I agree. Do you want to do it or should I?

[ded]

you can have a crack at it. i will gladly have a look since there's quite a few things on my plate at the moment

[stereokai]

I'll start looking into it in the next couple of days, I'll update here as I go

[danro]

FWIW, in my animation library.. I opted to ignore the requestAnimationFrame callback parameter, and decided to call the now() function on each frame. You can find the shims here if you're interested:

https://github.com/BKWLD/tram/blob/f2ee789efa9cba498b2e96ff5f566eb8793c057e/src/tram.js#L60-L83