With the rumors of WebGL being more broadly supported, especially IE, the promise of a true cross platform set of GPU APIs is almost there, I personally believe that this will change lots of things on the web, especially how people develop interactive content but I also hope it will push the web forward.
WebGL for 2D too
When we developed Stage3D in Flash, we wanted to expose low-level primitives to allow people to develop the frameworks they need on top of it. Game developers especially want that level of granularity to control everything and get the best performance out of it. On the other hand, we knew that most developers would not use the low-level GPU primitives and would prefer using a higher-level API exposing primitives that they are familiar with. That’s why we created Starling, which rapidly became the defacto framework for 2D content on top of Stage3D. With that, Rovio shipped Angry Birds on Facebook and more recently Zynga shipped Ruby Blast.
But WebGL will not only help gaming, it will also be useful to power interactive experimentations or parts of a digital marketing websites like we have seen on thefwa.com for many years and traditionally delivered through Flash. It can also revolutionize the way developers build mobile applications. The smooth UI components you appreciate on your phone are all GPU accelerated, powered by OpenGL ES 2 (iOS, Android) or DirectX (Windows 8). I hope lots of UI frameworks will emerge, to provide blazingly fast GPU accelerated UIs on top of WebGL. Feathers is a good example of that, that could be powered by WebGL.
Does this mean that we will do everything through WebGL? No, it all depends on the content and use cases, a classic DOM styled with CSS works great for more text based content, like a news website, a forum, or simple forms applications and the CPU is great at things like font rendering or vectors and many other things, but the combination of the two (CPU or GPU based renderer) will be a very powerful mix.
Implicit vs explicit
Use this property, but make you sure you don’t nest anything, and by the way make sure you set the alpha to zero, but never remove the element from the DOM.
What you want is low-level primitives (like WebGL) to be exposed and let people develop higher-level frameworks on top, this is the most flexible model. You have a performance issue or a bug, you can fix it. You don’t like the architecture of a framework, you replace it, cause all that code is then content based, not browser based. That was the idea behind the DOM.js project.
One recent example is the use of translateZ (CSS3) to force GPU acceleration. Here again, the problem with that approach is that you are using a hack which will have side effects. Originally developed for 3D effects, developers are now using translateZ for 2D effects without really knowing what is happening behind the scenes implicitly. What happens is that the DOM element you want to accelerate is rasterized (this simple first step could be costly if the element you are using has lots of nested children) then the bitmap is uploaded to the GPU behind the scenes (note that you never called any upload API) and then blended on the page. By the way, if the texture is too big, it will probably blow the device running out of memory, leaving the developer in the dark.
The importance of higher-level frameworks
Is it still the web?
Just like 2D canvas, WebGL renders everything inside a canvas too, which is pretty much a black box. This model is acceptable for games or some interactive pieces, which are generally not SEO friendly or accessible, but if more 2D interactive content is powered by WebGL, like applications, such content will probably need to be accessible, something that would not work today, but that is with the limitations of today and this could probably change. Why should only the classic DOM be accessible?
Here again, WebGL could introduce new ways of doing of things which could help move the web forward.
Pushing the web forward
Before Stage3D in Flash, the main bottleneck was the graphics pipeline, ActionScript 3 was actually fast enough to power most display list or blitted content relying on BitmapData, but once Stage3D got introduced, the situation changed and ActionScript 3 became the limitation. Developers started developing high-level frameworks, which moved lots of expensive code that would traditionally sit on the native side onto ActionScript 3. Code like tree traversal, bounds or matrices calculations and more were now happening at the ActionScript 3 level, pressuring the VM and maxing out the CPU.
If you are interested in hearing more about asm.js, John Resig jut posted a great article about it.Posted on April 3, 2013 by Thibault Imbert · 1 comment