<div id="red" class="centered"></div>
<div id="blue" class="centered"></div>

As you can see, the red div stretches to stick to the containing div borders, but the blue div keeps its dimensions and is centered.

Namely, CSS 3 transformations, transitions and animations, HTML 5 canvas or WebGL are the new kids on the block (for those wondering: yes, I was a teen in the 80s), and have received a lot of attention since a certain mr jobs claimed that no flash plugin would ever make it to his products.

So: what happens when a browser feature becomes widely implemented and popular ? Competition between implementations, of course !

The trouble is that it may be relatively easy to evaluate javascript performance (although one may argue that event javascript benchmarks are biased), but it is a bit more complicated to evaluate actual browser framerate.

How browser rendering is implemented

Typically, and although they may use background processes to perform specific asynchronous tasks (such as resource downloads for instance), web browsers do render each web page in a single thread, splitting the CPU time between javascript and rendering tasks.

Typically, on every frame, the browser executes some javascript functions piled in a javascript code queue (with a priority given on timed functions) for a given amount of time (typically 50ms), and then checks whether the page needs to be refreshed or not. If the page needs to be refreshed (either because, the DOM itself has been modified or because a new CSS rule modifies the layout, or for many other reasons …), it calculates the new page layout, isolates the portion of the page that it needs to refresh (sometimes called the “damaged” or “dirty” region), and renders it to its “backing store” (typically an internal buffer where all the drawing stuff occurs). Once done, it pushes the modified frame on screen using whatever mechanism the host operating system provides.

The important thing to note here is that ultimately, the operating system video drivers decide when the frame is actually pushed to screen: this means that trying to achieve a framerate that exceeds the video output synchronisation rate (typically 60Hz) is useless. As a matter fo fact, most browsers have a “framerate cap” hard-coded somewhere to avoid unecessary rendering operations (Chrome provides an option to remove this cap in about:flags).

Why javascript alone can’t be used to calculate FPS

Since actual frame rendering is not directly related to javascript based DOM or CSS modifications, relying solely on javascript loops to measure an animation framerate will most likely lead to very optimistic results (see for instance the Bubblemark javascript based benchmark that gives awesome results even when the actual rendering looks completely frozen).

Even worse, with CSS triggered animations, there is no way for the javascript to be notified of a new frame being rendered (actually, the whole point of this new CSS stuff is to avoid the javascript overhead).

How CSS can be used to calculate FPS (with a little javascript also)

Having thought a little about this issue, I came up with the idea of using CSS itself to evaluate the actual rendering framerate of a page.

The principle is quite simple:
- insert a very simple CSS animated item in a page,
- calculate the computed position of this item at regular intervals,
- every second that has elapsed, count the number of different positions occupied by the item.

Pretty dumb, uh ? Well, maybe, but it gives surprisingly accurate results, actually …

Obviously, this only works on browser supporting CSS transitions/animations, but these are actually the implementations we want to evaluate, so this isn’t really an issue.

The FPSMeter script

I have developed a little script that does just what I’ve described in the previous paragraph.

Get the script Here.

Here is a brief HowTo:

1 – Include the FPSMeter script to your page

    <script type="text/javascript" src="<path_to>/FPSMeter.js"></script>

2 – Add two call-back functions to your page to monitor progress and gather the final results

function log(fps){
// Do some stuff here with current FPS
}
function end(minfps,avgfps,maxfps){
// Do some other stuff here with min, max and avg fps
}

3 – In your page initialization code, instantiate an FPSMeter object, providing the call-backs as parameters

fpsMeter = new FPSMeter(log,end);

4 – Run the FPS meter for n seconds

fpsMeter.run(n);

Click on the picture to see the live version.
It works on Chrome, Safari and Firefox.

At the same time, the development of native applications on smartphones & tablets have raised the users level of expectations towards GUI to a point that “plain old web” user interfaces are not an option anymore.

But do current implementations live up to the expectations ? This has yet to be demonstrated …

The sad truth is that even on desktop, the CPU alone cannot cope with the level of complexity that is today required to develop a fancy user interface, and browser vendors are struggling to take advantage of hardware accelerations provided by blitters or GPUs. Due to the huge diversity of hardware configurations available, this leads to a very fragmented landscape for the poor web developer.

That said, how can we users help things getting better ? By providing feedback on how well their implementation behave to the browser developers …

For that purpose, I have designed a small browser animation benchmark test that calculates the number of frames the browser is displaying per seconds while an animation plays.

Note: If you want to know how the framerate is evaluated, see this post.

It now only works for Firefox, Chrome, Safari and Opera (IE is not supported).

It currently only tests CSS 2D features, but I will add more tests later.

At some point in the future I will also try to add some mechanism to have results gathered in a database, but in the meantime, you can post your result as a comment, specifying your hardware configuration, operating system and browser version.

Click on the link below to benchmark your browser.

kaizoumark

Some results:

On a Dell Latitude D620 Laptop running Windows XP:

Chrome 13.0.782.24

Firefox 5

Safari 5.0.3

Opera 11.11

On an Iphone 3GS running iOS 4.3.3:

Basically, you can specify in a specific file called the “cache manifest” the caching policy to apply to a particular web page.

To activate the HTML 5 caching feature for a specific document, you only need to specify the URI of the cache manifest file in the manifest attribute of the <html> element.

<!DOCTYPE HTML>
<html manifest="myapp.cache">
...

The file that references the cache manifest file is called the master entry.

Please note that to be properly parsed by the browser, the manifest file must have a text/cache-manifest MIME type (which means that you will need either to add a custom file type extension binding to your web server or to specify manually the mime-type, for instance using PHP header directive).

A cache manifest file typically looks like this:

CACHE MANIFEST
index.html
style.css
images/logo.png

NETWORK:
search.php

This file specifies several files to cache (the cache explicit entries), and then specifies that search.php should never be cached (it is said to belong to the online white list), so that any attempt to access that file will bypass the cache.

Whenever the user browses to the page corresponding to a document to which a cache manifest is associated, the browser must check on the server if the latter has been modified:

• If it hasn’t, then the cached content is used,
• If a new version of the cache manifest exists, then the cached content is considered as staled and reloaded from the server.

The cache manifest for a document may also contain fallback entries that can be used if the browser can’t retrieve the original content. Below is an example where a static image is used when the retrieval of a dynamically generated image fails:

CACHE MANIFEST
FALLBACK:
images/mirror-effect.php server-busy.jpg

HTML 5 also defines an application cache API to manually trigger cache updates:

• update(): updates the cache for the current document in the background,
• swapCache(): reflow the HTML document using updated cached content,
• onupdateready(): event triggered when the cache content has been updated,
• onobsolete(): event triggered when the cache content has been marked as obsolete,
• …

Two new HTML elements have been defined for that purpose: <audio> and <video>, based on the generic media element type.

Media elements use a common set of attributes:

• src: defines the source of the media to render,
• autoplay: boolean to activate|prevent immediate playback,
• loop: boolean to activate|prevent automatic looping on content,
• controls: boolean to display|hide browser playback user interface.

<video> and <audio> elements can contain elements to be displayed to the user in older browsers that do not support these new elements.

Below is an example of how to use the <audio> element:

<audio src="audio.ogv" controls width="100" height="50">
    <a href="audio.ogv">Listen</a>
</audio>

Alternatively to the src attribute, the content to be rendered can be specified using one or more <source> elements, each of them describing a specific media resource.

Each <source> can be identified by its src and type attributes, optionally complemented by a codecs attribute:

<audio controls width="100" height="50">
     <source src="audio.ogg" type="audio/ogg; codecs=vorbis">
    <source src="audio.spx" type="audio/ogg; codecs=speex">
    <source src="audio.oga" type="audio/ogg; codecs=flac">
</audio>

The <video> element has an optional poster attribute that can be used to define an image to be displayed before the video is played:

<video src="oggy.ogv" poster="oggy.jpg" />

These new media elements also support a set of handy javascript method, properties and events, to allow the fine-grained control of the rendered UI.

• play()
• pause()
• currentTime: current playback time,
• duration: overall duration of the media,
• playbackRate: playback speed (can be negative !),
• onplay(): content has just start playing,
• onpause(): content playback has just been paused,
• onerror(): an error occurred,
• …

<script>
function playVideo(url){
     var video = document.getElementById("video");
     video.setAttribute("src",url);
}
</script>
<video id="videoPlayer" controls=false/>
<p>
     <button type="button"
             onclick="video.playbackRate = -2;">
         Rew
     </button>
     <button type="button"
             onclick="video.play();">
         Play
     </button>
     <button type="button"
             onclick="video.pause();">
         Pause
     </button>
     <button type="button"
                 onclick="video.playbackRate = 2;">
         FF
     </button>
</p>

• <section>: represents a document or application section (a content column for instance),
• <article>: represents an independent piece of content inside a document/section (a blog entry for instance),
• <aside>: represents a piece of content not directly related to the displayed content (typically a sidebar),
• <header>: represents a document header,
• <footer>: represents a document footer,
• <nav>: represents a block of navigation links (typically a blog navigation bar),
• <dialog>: can be used to render a chat session, using complementary <dt> (talker) and <dd> (quote) tags,
• <figure>: can be used to provide textual information about an embedded content,
• <address>: represents a document/section contact block,