scrollability
scrollability copied to clipboard
Use requestAnimationFrame instead of setInterval, save cpu cycles for animation
Use requestAnimationFrame instead of setInterval, save cpu cycles for animation when this api is available. This helps slowly android browsers a bit.
another option, which combines both (requstAnimationFrame and setInteral) is described by Joe Lambert: http://blog.joelambert.co.uk/2011/06/01/a-better-settimeoutsetinterval/
@rsaccon the code in question can also be found/forked here: https://gist.github.com/1002116
It offers the performance improvements of requestAnimationFrame (when available) but doesn't require a code refactor to explicitly support it.
A few feedbacks: adding this really slows down the scrollability at least on Android devices.
After a bit of investigations, I :
-
Used simple variables and passed the check as argument: var requestAnimFrame = function( jsRequestAnimFrame ) { if ( !jsRequestAnimFrame ) { return ... } else { return ... } }( window.webkitRequestAnimationFrame || window.... ); and of course included it in the scrollability scope ( like Tin patch )
-
Plus inside requestAnimFrame and requestInterval, replace respectively window.setTimeout by setTimeout, and window.setInterval by setInterval.
It looks to works as it used to be, a little bit better on Android ( maybe because of 1000 / 16 instead of 0 as period ? ) Actually nobody mentions it's not supported on iOS, neither on Android at the moment. *
- Looks promising on the press release from March... or some chrome / other webkit upcoming releases...
- At the time of writing, tested with iOS 4.3.X and Android 2.1 - and since the time of scrollability was released, it hasn't changed so much: no support on mobile webkit-based browser for requestAnimationStuff
Snif snif
We are facing serious performance issue in android too, especially the honeycomb on tablet. We need a big breakthrough, but seems we are blocked by lacking of hardware acceleration for css3 transformation.
my solution is to not support android ;)