Retrieving requestAnimationFrame with JavaScript
The requestAnimationFrame function has been a major boost to developers creating and managing animations with JavaScript. Paul Irish has an excellent introduction on requestAnimationFrame -- I highly recommend you read it. This HTML5Hub post is also very good. Most browsers now support the animation function but in the case a browser doesn't, you can shim a rough equivalent with setInterval:
var requestAnimationFrame = window.requestAnimationFrame
|| window.webkitRequestAnimationFrame
|| window.mozRequestAnimationFrame
|| window.msRequestAnimationFrame
|| function(callback) { return setTimeout(callback, 1000 / 60); };
requestAnimationFrame was implemented with browser prefixes so we'll check for those if the unprefixed window method isn't there. If no native implementation exists, a setInterval shim will have to do!
![Serving Fonts from CDN]()
For maximum performance, we all know we must put our assets on CDN (another domain). Along with those assets are custom web fonts. Unfortunately custom web fonts via CDN (or any cross-domain font request) don't work in Firefox or Internet Explorer (correctly so, by spec) though...
![9 Mind-Blowing WebGL Demos]()
As much as developers now loathe Flash, we're still playing a bit of catch up to natively duplicate the animation capabilities that Adobe's old technology provided us. Of course we have canvas, an awesome technology, one which I highlighted 9 mind-blowing demos. Another technology available...
![9 More Mind-Blowing WebGL Demos]()
With Firefox OS, asm.js, and the push for browser performance improvements, canvas and WebGL technologies are opening a world of possibilities. I featured 9 Mind-Blowing Canvas Demos and then took it up a level with 9 Mind-Blowing WebGL Demos, but I want to outdo...
![Table Cell and Position Absolute]()
If you follow me on Twitter, you saw me rage about trying to make position: absolute work within a TD element or display: table-cell element. Chrome? Check. Internet Explorer? Check. Firefox? Ugh, FML. I tinkered in the console...and cussed. I did some researched...and I...
According to caniuse, Microsoft’s browsers never had a vendor prefixed version of
requestAnimationFrame, so we can just keepmozandwebkit.That’s a very common way to normalize the function, but in most recent implementations
requestAnimationFramepasses an argument to the callback function, which is the amount of milliseconds sinceperformance.timing.navigationStart, with micro precision too. This can be very handy for the callback.It’s not really possible to perfectly emulate this, but you can get something close if you take note of the epoch time as soon as the script is executed. So this is how I used to polyfill
requestAnimationFrame:(function(start) { window.requestAnimationFrame = function(callback) { return setInterval(function() { callback(new Date().getTime() - start); }, 1000 / 60); }; })(new Date().getTime());(Well, not exactly… since most of the times
requestAnimationFrameis called again in the callback function, but the function itself takes some milliseconds at least to be executed – because it probably involves some kind of repaint – and you should adjust the time interval accordingly, or you may never hope to even get close to 60 fps.)Also, don’t forget to normalize
cancelAnimationFrame, which has a nasty variant in some (and maybe forgotten?) WebKit browsers:webkitCancelRequestAnimationFrame.