RequestAnimationFrame powered iScroll v4.1

Everyone’s excited about iOS5 native position:fixed support, but as I explain in a recent post javascript scrollviews are far from retirement. So with renewed enthusiasm here I introduce you to iScroll v4.1.

Please allow me a quick digression before adventuring into the iScroll news. It came to my attention that iscroll.js has been included into a couple of big projects without the copyright notice. The script is MIT licensed, the most liberal license out there. You can use, alter, distribute, sell the code free of charge without restrictions. All I ask is to place buried (but accessible) somewhere the copyright/permission notice.

You can place it into the script itself, you can place it in an about/bibliography/credits page, you can even just link to it, but you are required to show it somewhere. If you can’t directly include it into the application a quick mention in your dev blog might do the trick. I’m open minded, be creative.

If for any reason you absolutely need to remove the notice, please contact me and let me know why you need to strip it out. I’m sure we can find an arrangement (no, that doesn’t involve money).

Don’t believe my words? Believe your eyes, in the source code they include an old version of iScroll (so Apple seems to care about copyright only when they are the copyright holders).

Update: Apple placed the copyright notice back.

The copyright notice is *not* to pump my ego. Showing the open source license lets people know that they can re-use the script freely.

Now, back to business. iScroll 4.1.

iScroll v4.1 is all about performance, stability and optimization. First of all I got rid of transitionEnd event and I’m using requestAnimationFrame instead.

requestAnimationFrame is a relatively new function available in some modern browsers that should guarantee a smooth animation. Basically, as soon as the first frame has been drawn you ask the hardware to paint the next one, you are not forcing the device to animate at a speed that it can’t handle. You may argue that webkit doesn’t support requestAnimationFrame, but fear not, iScroll gracefully degrades to less fortunate browsers. Hopefully Apple will support it in future releases.

This new technique also gives us back the shrinking scrollbars (scrollbars resize when dragging over the boundaries) and a slightly better performance on Android (transitionEnd seems a bit dodgy on the google phone).

Zoom has also changed. I’m not using gesture events anymore but I’m tracking each finger from within touch events. Fingers tracking (believe it or not) is easier to handle than gestures, the code is more compact, touches do not overlap with gestures, and everyone’s happier.

v4.1 also introduces a wider browsers compatibility. Firefox, Opera, Chrome and Safari are almost 100% supported. IE9 will be the next step. The code needed to achieve desktop compatibility does not impact mobile performance, so there’s no reason not to include it.

There are still some glitches here and there (especially in the zoom), but the core should be rather future proof, so let the forks and pull requests begin. In this regard, I wanted to thank once again all those who submitted bug reports and suggestions. I was working on this new version (that if you look at the diff is almost a complete rewrite) and I wasn’t able to directly merge your code, but I took inspiration from all your submissions!

In the coming days I’ll update the documentation to match the new features. In the meantime if you are using “pull to refresh” do not update! The functionality has been removed from the core and will be soon reintegrated as a plugin. For all the others… go get it or look at the demo.

31 thoughts on “RequestAnimationFrame powered iScroll v4.1”

    1. Just finished testing. It’s really improved. Fast, less glitch, cool!!!

      What is the different between myScroll.disable() and myScroll.stop()

      If it’s disable then I can enable it.
      But when it stop, how can I scroll it again?

      Thanks, I love it.

    2. APIs documentation tomorrow. Sorry 🙂

      stop() basically stops any residual animation. It is indeed possible to programmatically schedule keyframes.

  1. Looking forward to checking out iScroll v4.1, thanks for posting this. Also, thanks for posting your explanation of when/where the new iOS5 native position:fixed and overflow options work and where they don’t.

    I looked at the example you provided above of Apple not including the MIT copyright notice in But that looks like a minified script. I’ve wondered about this for a while — when you minify a js file, it removes comments, including copyright notices that are commented. So where would be an place close to the code to include a copyright notice with minified scripts? Thanks.

    1. you should reapply the notice to the minified version. To keep the file small you can just add 1 line comment with a link to the full notice.

  2. How about function embedded in the script that prints the license to the console on every load?

    Crap, that’s a good idea. I think I’ll do that on my stuff.

  3. Thank you for new version of iScroll!

    However, on my iPhone 4, performance is much worse than iScroll 4.0 Beta 4, seems to be scrolling at about 15-20 FPS.

    And I found one bug – scrollToElement() doesn’t work while the scroller is decelerating.

    1. Unfortunately, these changes have no effect…

      (I updated the testcase with 4.1.2 and translate3d)

    2. I’ve quickly hacked your 4.1 code and reverted to transitions technique instead of setTimeout fallback, and I can say it’s much smoother now.

      It’s a bit unfortunate to use setTimeout/setInterval on iOS, because it’s pretty inaccurate – in my experience, I had problems with accuracy of 200ms interval on iPad when CPU was busy.

      I did some benchmarks how accurately iScroll 17 ms interval fires on iPhone 4 – surprisingly, majority is 17-18 ms, but there are few 23-25 ms, and even 35-41 ms delays (that’s below 30 FPS, so then iScroll animation appears choppy)

  4. I think my biggest complaint is that the “rubber-banding” at the end of scroll doesn’t really match iOS at all. iScroll momentum is really weird when it hits the end of a scrolling area, and doesn’t feel natural. It should sort of “snap” past the page and slowly ease back into place.

    1. as mentioned in the article, it is not supported by “standard” webkit, but it is supported by chrome (so eventually android will get it). It’s little more than an experiment right now, let’s see how browsers evolve.

    2. Cool thanks. I agree requestAnimationFrame is a great step in the right direction. Makes performance in Chrome much better than Safari for a lot of animation based stuff.

  5. Thanks for the excellent utility! I’ve only just started developing for iPad/mobile browsers and this tool saved me from having to do a complete template redesign!

    Any idea when IE9 and IE10 compatibility will be available? At the minute I have to do browser detection to disable the iscroll for some browsers because of the IE9 compatibility issue.

  6. Matteo: I am using iscroll-lite.js. Until version 4, it would render scrollbars. The new version no longer renders scrollbars. Why is that? Do I need to define my own CSS for scrollbars? If so, how?

    1. Performance degradation in iScroll with or without scrollbars is close to zero. Use Lite version if you need the scrolling and nothing else. If you need scrollbars I suggest to use standard iScroll.

  7. I was checking out the Tablet website of and it uses iScroll. Nice use there but they removed the copyright.. That`s sad that big companies remove it, like Apple did a while.

  8. Please i am Having trouble while zoom the whole page. When integrating the Iscroll into a div the page zoom doesn’t work anymore…any suggestion? Thx.

Comments are closed.