here<\/a>.<\/p>\n\n\n\n\/\/ Polyfill for rAF\nwindow.requestAnimFrame = (function() {\n return window.requestAnimationFrame ||\n window.webkitRequestAnimationFrame ||\n window.mozRequestAnimationFrame ||\n function(callback) {\n window.setTimeout(callback, 1000 \/ 60);\n };\n})();\n\n\/\/ Throttling function\nfunction rafThrottle(fn) { \/\/ takes a function as parameter \n var busy = false;\n return function() { \/\/ returning function (a closure)\n if (busy) return; \/\/ busy? go away! \n busy = true; \/\/ hanging \"busy\" plate on the door \n fn.apply(this, arguments); \/\/ calling function\n \/\/ using rAF to remove the \"busy\" plate, when browser is ready\n requestAnimFrame(function() {\n busy = false;\n });\n };\n};\n\nvar mousemoveHandler = rafThrottle(function(e) {\n \/\/ same code as before \n});<\/code><\/pre>\n\n\nHow could we handle touch events?<\/h3>\n\n\n
You can find this code in the demo. It’s just one additional handler for touchmove<\/code>, which does same stuff as mousemove<\/code>. I decided to not write about this in article, because even after the rAF performance optimization, the mobile performance kinda sucks compared to the original website (jetlag.photos), which works through . Still, it’s not too<\/em> bad considering it’s images in DOM elements.<\/p>\n\n\n\nSome browsers have additional problems with black lines on the edges of the slices. This problem appears because of combination of width in % and 3D transforms during the movement, which creates sub-pixel rendering issues, and shows the black background through the cracks.<\/p>\n\n\n
That’s all!<\/h3>\n\n\n