WebGL – Not just for 3DThursday, November 18th, 2010 by Sebastian Markbåge
UPDATED: The demos are now updated to work around some bugs in the ANGLE implementation currently in Chrome 9 beta and Firefox 4 beta 8.
Safari, Chrome and Firefox all have WebGL enabled in their latest betas/nightly builds. Opera is on the working group as well. Additionally modern iOS and Android devices have OpenGL ES support so mobile support is probably not far away. Firefox already has WebGL support on Maemo.
Microsoft is not yet on board
While Microsoft is constantly bragging about the fully hardware accelerated rendering in IE9 using DirectX. They’re the only one of the major players not yet in the WebGL working group. WebGL is supposedly designed so that it can be implemented on top of DirectX. This allows for stronger implementations on Windows where OpenGL support is poor. Mozilla and Google are already doing this in their implementations.
Microsoft obviously have a lot invested in DirectX and may not want to support an API so close to the competing OpenGL. However, given their recent effort to support standards I’m hopeful they’ll get on board for IE 10.
Given that no browser supports WebGL yet, other than in beta versions. We will obviously need some fallback.
For any proper 3D beyond gimmicks you’ll want to use hardware acceleration. The exception being data visualization.
Flash and Silverlight already have pixel shader support. This doesn’t help 3D much but they do help for 2D special effects etc. Although these are not hardware accelerated, they can run multi-core and they’re faster than anything you can do with 2D canvas.
Additionally Adobe has announced hardware accelerated 3D support through the Molehill APIs. I’m sure Microsoft is not far behind with Silverlight. Once these get out to IE users, we’ll have direct hardware capabilities on all the major platforms.
WebGL is a horrible looking API. It’s intentionally a direct translation of the C interface. The intension is that people will provide abstractions on top of it. E.g. a general game engine or a data visualization API built on top of it.
Some have tried to make thin wrappers around it. Like MooTools or jQuery wraps the DOM in a thin API abstraction. I think that is a mistake. You really need to optimize for performance and to do that you need a higher level abstraction that works directly to the WebGL API.
I have no intension of making a thin GL wrapper nor a single generic 3D API. Although…
It’s not just for 3D
Those of you following me on GitHub know that I’ve been doing a lot of work on the MooTools vector graphics library – ART. We already have great SVG and VML support. Next for me is to focus on high performance scenarios.
To start off, I’ve implemented two 2D use cases that are otherwise difficult to do properly using CPU only.
A Diffusion Curve is a new vector primitive. To understand what they are and why they’re incredibly cool, I recommend watching the video from the authors of the original research paper. Implementing a rasterizer of Diffusion Curves involves a diffusion and blur step that are both very computationally expensive. However, using a clever implementation you can take advantage of GPU hardware acceleration to get acceptable performance. There have been talks about introducing diffusion curves in SVG 2.0. But until that gets into browsers, we can already use it through the power of WebGL.
A page curling effect can be implemented many different ways. However, to get a smooth realistic effect on dynamic content you really need some acceleration. This applies to many special effects that you can apply to 2D content.
Safari doesn’t implement SVG filters yet. Such filters can be implemented in terms of WebGL and extended further to advanced blending effects and crazy transforms.
Learning more about WebGL
Lessons Learned – WebGL
Lessons Learned – Diffusion Curves