You may look at the image above and think it’s a classic visualization from the mid 1800′s. You’ld be wrong, as it’s actually a recreation of an old visualization done by Jim Vallandingham using d3 and Coffeescript for a native HTML5 version.
I choose to try out d3.js for this experiment. This is a javascript framework that is the official successor to the popular Protovis visualization toolkit. d3 allows you to represent your data with native svg elements, which provides a lot of power in terms of layout and style. Furthermore, to make writing javascript more fun, I wrote the visualizations in coffeescript – a language that compiles down to javascript.
Downloadsquad takes the four major browsers for the windows platform and compares them against one another in HTML5. It turns out that IE9 and Firefox 3.7 both use Direct2D to utilize the GPU’s rendering power. That makes them the best choices for HTML5.
Sean Christmann has some new demo’s up on CraftyMind showing some of the fun stuff that HTML5′s Canvas and Video tags enable. He shows how you can, relatively easily, interact with live video with a simple “explosion” demo and rotate it in 3D. He also brings this up:
Don’t ask me why, but copying pixel data out of a video tag is expensive, so expensive that drawing it into a temporary canvas, and then drawing pieces of that temp canvas onto a final canvas is faster then just referencing the video tag repeatedly within the same loop. That’s why you’ll see 2 Canvases in the source code for the demos. I’m sure there’s a technical reason for this duplication process, but it’s a lazy reason.
My guess would be that accessing the Video object directly gets into many levels of very complex API’s for decoding the live stream, simply adding a lot of overhead as it finds keyframes, re-decodes to the requested frame, and deals with the overhead of various codecs. Once you copy it into a canvas, access is a simple (x*width+y) operation.
A new charting library is on the block, this time working entirely with HTML5: rGraph.
RGraph is a HTML5 canvas graph library. It uses features that became available in HTML5 (specifically, the CANVAS tag) to produce a wide variety of graph types: bar chart, bi-polar chart (also known as an age frequency chart), donut chart, funnel chart, gantt chart, horizontal bar chart, LED display, line graph, meter, odometer, pie chart, progress bar, pseudo radar chart, scatter graph and traditional radar chart.
Using only HTML5 and Canvas means No Flash, which means they are viewable on an iPhone. (Unfortunately, all of the interactive features are nonfunctional, overriden by Safari for use in Pan & Zoom). Beta version is available now, with the first official release coming soon.
Both YouTube and Vimeo announced last week that they would begin to support (on a limited basis) the new HTML5 ‘Video’ tag that allows video playback without relying on Flash. The technology is impressive, but users quickly noticed that it didn’t work with FireFox. Odd, since FireFox is 3.5 compliant, but it seemed to only work with Safari and Chrome? Mozilla has finally come out with a response, and the big problem is that while YouTube and Vimeo are supporting a public standard (the HTML5 Video tag), they’re using it with a non-public proprietary codec, the classic H264. Mozilla believes that using this proprietary codec is a bad idea for both providers and consumers, and is instead pushing something more open like the OggTheora codecs.
Apart from the issues with H.264 support in clients, there are also huge issues around H.264 for Web authors and content providers. Currently providing H.264 content on the Internet is zero-cost, but after 2010 that will almost certainly change. (…) We won/t know much about the terms until the end of this month. The key issue is not exactly how much it will cost, but that if you want to publish H.264 you will probably have to hire lawyers and negotiate a license with the MPEG-LA. If you just want to put a few videos on your Web site, or add a help video to your Web application, or put a video cut-scene in your Web game, that is probably not something you want to do.
I particularly love this comment from Robert O’Callahan:
But the MPEG-LA won’t bother suing me or my project, we’re not worth bothering with. Perhaps true, but I hope “remain irrelevant” is not the favoured strategy for most free software projects.
Comments