Very poor JS timer granularity in iBooks/Safari on iPad?

Question

I am creating scripted e-books running under iBooks. They do animations using JS setTimeout and/or requestAnimationFrame. After extensive debugging of why animations were running so slowly, I found that the timer was firing, instead of in the 20-50ms that I requested (and get in Chrome or Safari on the desktop), at intervals more than 10 times that long, sometimes as long as one second or more (this is setTimeout, since apparently requestAnimationFrame / webkitRequestAnimationFrame are not available in iOS or at least in the iBooks-ized version of webkit).

After doing further research, I found out this this is apparently not an iBooks issue as much as an iPad issue--I find similar granularity in Safari on the iPad. Is this just a function of a slow processor (I'm testing on an iPad 2), as discussed here?

Or is this related to setTimeout being reported to not function during scrolling as discussed here (although in my case there is no scrolling involved)?

For your information, the types of animations I am doing are not ones that can be implemented using CSS animations which would potentially be hardware-accelerated.

Bottom line, does anyone have any ideas how to get finer timer granularity in JS on the iPad, whether in iBooks or Safari?

Answer 1

I have found the problem was that iBooks reads through the entire book when it is first opened, opening (and running scripts on) each and every page. Furthermore, it does not appear to correctly prioritize requests from the currently open page over its background page pre-reading work, so until the pre-reading process is finished, which could take dozens of seconds on a large, script-heavy book, timer responsiveness (whether setTimeout or requestAnimationFrame) on the current page can be dramatically impacted for the worse.