Closed ghost closed 11 years ago
currently not merging...
done
this still isn't merging. can you clean this up for a clean merge?
no. i mean do whatever you feel is necessary.
is still breaking?
@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
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
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()
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