search

ded / morpheus

A Brilliant Animator
504 stars 57 forks source link

Fixed requestAnimationFrame for good #35

Closed ghost closed 11 years ago

ghost commented 11 years ago

requestAnimationFrame was changed recently. The new version is used in Chrome 24 and IE 10. They had changed the first argument. Instead of sending the time stamp starting from epoch, they now send more precise timestamp in miliseconds starting from page load. So to resolve animation start window.perfomance.now should be used.

The discussion occured in mailing lists back in May: http://lists.w3.org/Archives/Public/public-web-perf/2012May/thread.html#msg36

ded commented 11 years ago

currently not merging...

ghost commented 11 years ago

done

ded commented 11 years ago

this still isn't merging. can you clean this up for a clean merge?

ghost commented 11 years ago

no. i mean do whatever you feel is necessary.

ded commented 11 years ago

is still breaking?

danro commented 11 years ago

@ded After review, it looks like this will conflict because it's a different approach to dealing with the new requestAnimationFrame timers. The currently merged approach #34, simply sidesteps the high-res timer features offered in IE10 and Chrome 24, where as this pull requests attempts to add support.

I'd like to see the high-res timer supported, myself- rather than force the new browsers to use the older (low-res) timer methods. Here's an article that covers the new timer changes:

http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision

ded commented 11 years ago

ugh. ok. this explains a lot. however we should be using performance.now — this is what i get for not full reading the new api

danro commented 11 years ago

Here's an interesting snippet.

startTime = window.performance && window.performance.now ? (performance.now() + performance.timing.navigationStart) : +new Date();

Can't we just change the start time? Seems like it would be more performant than checking the time value on each run()