The dom::Win.reqAnimationFrame() is currently defined as:

Void reqAnimationFrame(|This| f)

But the callback should be passed the timestamp as per the spec, as in:

Void reqAnimationFrame(|This win, Duration timestamp| f)

See:

• MSN Window.requestAnimationFrame()
• requestAnimationFrame running slow on weak machines. Work around?

If you know the timestamp, then the function can tell when a frame has been skipped due to slow running etc, and amend / adapt the animation to keep it smooth.

I guess you could keep track of the timestamp yourself, but if it's already provided...

I'm a little reluctant to add that for 2 reasons:

• You take the boxing hit on that value every ~16ms
• As you noted, its redundant with grabbing the time yourself via Duration.now

So it appears it would be easier to optimize that method if we pushed the timestamp check into the callback function.

The ms resolution from Date is probably sufficient for browser land, but separately we might want to look at updating Duration.now to use performance.now() since that appears to have good browser support these days.

update Duration.now to use performance.now()

That sounds good - here's a simple shim for those browsers that don't natively support it: performance.shim.js

You take the boxing hit on that value every ~16ms

Given the amount of processing, calculations, and rendering that occurs every animation frame (~16ms) for a computer, laptop, tablet, or phone (on all of which Escape the Mainframe runs quite reasonably) - does one Duration object creation make such a difference?

If a device can't handle that, then I seriously question it's ability to process Fantom and / or Javascript. Let alone fluid animations!

Its less about CPU than memory - you are tossing a new allocation onto the heap 60 times a second :)