So there is much chatting going on about the new IE9 and the fact that this time Microsoft tried to adhere to web standards much more than it used to do in the past. Namely:

• HTML5 for videos (H.264), which means that we will be holding a Adobe “Flash For Video” funeral pretty soon now. I notice that most geeks don’t care about usages of Flashes besides videos, but there are still many of them (both filling gaps in HTML standard, like in the case of multi-file uploads, and for animations/interactions/games where HTML5 Canvas+JS is still too slow).
• Fast JavaScript engine: aka JIT. Given how slow IE8 is in benchmarks, this is very good news for development of rich web applications on the Internet.
• CSS3, DOM, SVG: they are really supporting a lots of new features available in nowadays standards. I think the support for SVG will make many people wonder if Christmas came for Easter this year. And yes, it is indeed coming.

A very interesting news is that Microsoft is announcing GPU Acceleration for IE9. Now, we are a little short on details (and I’m not at MIX10 where IE9 is being presented) but I still see legends floating around.

Microsoft: not so much graved in stone anymore, it seems (Image via Wikipedia)

First, there is absolutely no way that IE9 (or any browser, for that matter) could offload to the GPU the whole Javascript engine (and not even the compilation step required by the JIT). Modern GPUs are massively paralleled calculators. They are very good at executing a 100-lines mathematical function at the same time in 4096 cores, which is exactly what you need to do graphics (2D, 3D, whatever) and heavy calculations like physics, simulations, and so on; but they can’t really go beyond this. Moreover, there is a measurable overhead in starting each GPU task (use DMA to fill internal memory, upload the task) and fetching results (DMA the results off the video memory into main RAM).  So there is basically no way to use such a horse for running custom Javascript code.

In fact, what Microsoft is saying is that it will recompile Javascript in a different thread/process, offloading it to a different core of the CPU. This is probably a step forward in the right direction. IE8 already had a multi-process architecture much like Chrome does, and offloading the JIT itself to another process looks like a very good idea. I wonder what Chrome developers think of it.

So, what about GPU acceleration? It will be used in these main areas:

• Video decoding: Modern video cards have hardware support for H.264 decompression. This is already supported by Windows drivers, and if you use a Windows system to watch a H.264 HD video, you will see that the CPU usage is indeed pretty low. Alas, since H.264 is a patent encumbered format, this acceleration is not supported in Linux and probably will never be. The most Linux can achieve is YUV HW compositing, which is nothing like offloading the whole H.264 decoding to hardware.
• HTML5 Canvas: through the new Direct2D API, it will be easier to leverage hardware acceleration within Canvas. Notice that Direct2D, to the best of my understanding, is just a better API (both at the user-space level and driver level) to access the existing programmable graphics hardware. It is not different from what Cairo or Qt’s QPainter already offer, but it is fully accelerated. If you use Firefox on Linux, you get cairo -> xlib -> xrender, and then you’re doomed.
• Font rendering: rendering text is a big part in a browser, and the new DirectWrite API will take care of hardware acceleration for fonts. DirectWrite is a whole font-rendering stack that has been designed with hardware acceleration in mind. It is like Freetype of the next millennium. I believe there is absolutely no equivalent for DirectWrite in the OSS world.

I plan to do a quick benchmark of IE9 this week. I will specifically be focusing on HTML5 canvas rendering, since that is the part where it is meant to shine, even compared to Chrome.

Stay tuned!