14 DAY TRIAL // From the outside, there's a notion that web technologies are rather static, they evolve, obviously, but only major steps are advertised. But the technologies powering the modern web are in a state of flux, developers and browser makers are constantly adding new stuff and tweaking the existing methods.
At the same time, browser makers seem to be locked in lethal combat, trying to prove that their browser is the best. To a degree, this is true.
But most people would be surprised by the amount of collaboration or, alternatively, the amount of copying that goes on behind the scenes.
The web is about to get a lot more dynamic. With the HTML5 canvas tag, SVG animations, CSS3 transitions and WebGL, developers have a lot of tools at their disposal for bringing their sites to life.
But all of this can take its toll on the machine asked to process the increasingly heavy websites. Luckily, browser makers are on the case.
The Google Chrome team has announced the introduction of a new experimental API in the WebKit rendering engine that offers a new way of getting the browser to redraw frames in animations.
"The web is becoming more interactive and animated day by day. Many web pages use the Canvas element to draw rich 2D content via the 2D context or modify DOM elements on the fly," Kenneth Russell, Software Engineer at Google, wrote.
"These pages generally use the setTimeout or setInterval APIs to receive frequent callbacks, allowing them to redraw their content periodically, or use DHTML to move elements on the page. As 3D content drawn using the WebGL API increases in popularity, it will use similar animation techniques," he explained.
The webkitRequestAnimationFrame API switches the model around, enabling the browser to control the rate at which new frames are drawn to adapt it to the temporary conditions.
"Instead of the developer specifying a target frame rate, the browser runs the given callback when it is ready to produce the next animated frame. The callbacks are specifically known to be relevant to the animation of the page, and don’t run too often," Russell explained.
Mozilla was the first to introduce a solution to the problem. The mozRequestAnimationFrame API was revealed last summer and is built into Firefox 4. With webkitRequestAnimationFrame, Google has built the same functionality into WebKit, already available in Chrome 10, but also added some of its own.
webkitRequestAnimationFrame "supports an optional second argument which is the element that the callback intends to animate. This additional information will allow the browser to avoid animating elements that are not visible to the user," Google explained.
It should be interesting to see if Mozilla adopts this addition as well. The hope at Mozilla and presumably at Google is that RequestAnimationFrame can become a standard API that is adopted by all modern browsers.