I'm using the Three.js JavaScript library to do some things in WebGL, and I wonder how the graphic aspects of timers are done on mobile.
I was creating numbers with geometries and just replacing them when needed. This was fine on desktop (or so I think, lol). Recently, I've been playing around with mobile and the previous method is far too slow.
Graphics timing in modern browsers, including (especially) on mobile, is done via requestAnimationFrame(), introduced as a result of the W3C's specs on timing control for script-based animations, replacing the older setInterval() approach. Both call an event handler.
requestAnimationFrame() (RAF) ensures far more reliable / regular timing than setInterval() and the like. How it works (loosely) under the hood is to let the browser know that what is currently happening in the timed event handler is an animation, and as such certain measures should be taken (by supporting browsers) to ensure this process proceeds smoothly. And to quote MSDN:
simplifies animations by scheduling the next animation frame only when the system is ready to paint. This leads to smoother animations and less power consumption than previous animation techniques because requestAnimationFrame takes the visibility of the web application and the refresh rate of the display into account.
At least for Mozilla-based browsers and IE, RAF will typically match the display refresh rate and so generally guarantees a steady refresh period / frequency of around 60FPS, although admittedly Opera docs suggest that RAF does not guarantee this. In general, however, I would go with the Chrome/Firefox/IE recommendation, which is that you can rely on the rate noted above.
Under the hood, Three.js will be using RAF, or if the browser doesn't support it, will fall back to setInterval().
