The Promising Future for WebGL – Part 4: Obstacles to overcome

It’s no surprise that HTML5 has not yet delivered on all its promises. WebGL has some major dependencies on HTML5 issues being resolved before we’ll see many awesome games, efficient 3D content creation apps, or secure 3D enterprise apps. For simplicity, I’ve dumped the issues into two buckets, technical and non-technical.


In the specific case of 3D interactive applications, there are several issues that currently prevent HTML5 to be used as a practical delivery platform. In particular 3D hardware acceleration (GPU) is still not available as a mainstream feature. While the specification for WebGL exists, unfortunately it has not yet been widely implemented on major mobile devices (i.e., no WebGL access on iOS) and on major web browsers (no WebGL in IE 6/7/8/9/10 where the market is still so fragmented it will take years for IE users to migrate up to 10, even if it did support WebGL!) Google and Mozilla (Chrome and Firefox) have been providing an ‘experimental-webgl’ canvas 3D implementation for a while now, but it still suffers from driver issues (see the blacklist/whitelist for WebGL capable drivers). More importantly, the WebGL 1.0 specification is providing a subset of OpenGL-ES 2.0 specification while native applications on desktop have far more capabilities through OpenGL 4.x or DirectX 11.

Pretty much everyone with any knowledge of HTML5 (in general) will tell you that the largest challenge HTML5, and hence WebGL, face is security. Beyond the many blog posts, many Khronos meetings and HTM5 related conferences, security remains the greatest obstacle to HTML5’s adoption, particularly for enterprise and business productivity applications. HTML5 has other obstacles to overcome before becoming mainstream, and those coming from 3D support not the least of them. None of the outstanding API issues such as those maintained by the Khronos Group public WebGL forum will matter much until HTML5 architects and experts finds solutions to more pressing concerns such as security, but also UX (including supporting push notifications), the ability to handle a C++ API (a la NaCL beyond Chrome) or even compute on the GPU (WebCL) for web applications. Another issue with HTML5 is that it is limited on access to device specific hardware. In particular access to file system is very limited due to security concerns, but also to other important device specific inputs – such as camera, microphone, GPS, or simply USD (devices). This alone is preventing HTML5 to be used to create web “apps,” limiting its use to only web pages.


In addition to pure graphics acceleration, performance in general is a major concern, as JavaScript is a bottleneck for any intensive CPU activity. While there has been a lot of progress made on this and more to come in the future, the path is not clear (Google Native App? Dart replacing JavaScript? Some serious improvements in Javascript?) on how it will all get resolved. WebGL does solve the plug-in issue, as JavaScript now has access to the 3D accelerated features without the need for a plug-in, but it only scratches the surface. For instance, physics, animations, AI and other CPU intensive operations have to be done in the JavaScript engine, which lacks the performance for that type of content now expected by the consumer. WebGL itself is also limited to generic 3D graphics features, and is available on a limited set of hardware and browsers. So for the time being WebGL applications will be limited to nice looking demos, experiments and 3D augmented web pages.


When I look at the politics of WebGL adoption, browser providers such as Google (Chrome), Mozilla (Firefox) and Apple (Safari) all do a pretty good job supporting WebGL. However, Microsoft (IE) has yet to make a decision if they want to jump onto the WebGL bandwagon.  Whether they do or not, only time will tell if they lose market share for IE because of it, but their security concerns, and the way they look out for their enterprise IE customers, is admirable, if indeed that is their only true concern.

Mobile is a different story.

On mobile

You know WebGL for mobile has a way to go when one of the coolest things out there is actually a cute little platformer game that outlines the challenges of HTML5  game development for mobile. Look no further than the presentation game created by  Pascal Rettig on the  site based on his own engine, Quintus, This said, the big takeaway here is the promise of  very efficient WebGL game dev that fully utilizes all the features of HTML5, paring a  small platformer game such as the one shown on Quintus down to just 60 or so lines of code! Beyond the write once, deploy everywhere mantra HTML5 developers espouse, let’s not forget that HTML5 and WebG should also bring developers greater efficiency and simplicity since HTML5 with WebGL will be providing so much of what they need.
Why have we not seen WebGL deployed on mobile, specifically for mobile apps. Why? Apple iOS lockdown and Google’s Android group’s aversion to all things WebGL, for very solid business reasons. Apple, (and even Google Android) garners no immediate marketplace advantage by openly and fully supporting WebGL for mobile, and what they provide for app developers in their iOS  and Android toolkits is not only sufficient right now, but also maintains their enviable profitable (and closed) mobile app development position. I suspect Google’s Android team will come around much faster than Apple will.

Regarding the competition

Adobe and Unity stand out as proprietary platform competition for WebGL. Adobe is not as much of a sleeping giant as one might think and Flash has nicely advanced to accommodate hardware accelerated 3D via Stage 3D. The Stage 3D platform   has also gained enough traction to have its own ecosystem of viable support applications such as Flare3D, Away3D, Alternativa and Minko, – all linked to from the Adobe Stage 3D website.

Unity continues to gain traction with significant software updates (Unity Pro 4.0 is now out, and includes advanced animation support via Mechanim) and a strong developer user base (1.5M developers and growing). It’s highly likely that for at least the foreseeable years, it’s proprietary platform will continue to be used by indies, non-game  developers, casino gambling developers and other kinds of developers who care more about using Unity’s easy to use editor (and/or require a cross-platform solution) than an open web platform 3D engine.


Khronos made an intelligent decision to open up the WebGL working group to stimulate and encourage open discussion, and their public WebGL forum – where most key discussions take place, was the right move for enabling the most comprehensive WebGL spec development. The other issue however is conformance. While Khronos has done a pretty good job with conformance test creation and testing for OpenGL|ES and COLLADA, they  did not initially a) make the tests freely available to be used informally by implementers and thus have their products improved upon because of such testing or  b) market the test suites to developers who may not also be Khronos members. Frequently I see complaints about COLLADA being too complex and that COLLADA’s complexity hinders the “adoption of the standard,” but if they knew they could conform to Khronos’ COLLADA conformance suites, they would be more successful adopting, implementing and supporting the standard. Fortunately, that lesson has been learned for WebGL and Khronos is ahead of the eight ball on this one, providing an implementer’s portal on from pretty much the beginning.


There is no doubt HTML5 will evolve into a fantastic standard framework for interactive 3D applications such as games, but it will likely take years for HTML5 tools to catch up to the quality we find today for proprietary 3D platforms. The entire industry is converging with the concept of HTML5, although this is currently a moving target with many different variations. Apple has rejected Flash (and it’s plug-in technology) in favor of native apps, or HTML5 content. Microsoft windows 8 will use HTML5 and JavaScript for their new desktop interface. Google is pushing HMTL5 technology, collaborating with all the web browsers such as Mozilla, Opera, Safari. The effort is on open source software (WebKit, chromium,..) and open standards to expose hardware to the web browser (not just WebGL, but also WebCL, streamAPI…).

HTML 5 is slowly but surely adding all kinds of technologies into the web browser and exposing it to web developers. Perhaps because of HTML5’s collaborative and open nature, as well as the complexity to create and deliver something that does not introduce security issues, it may take years before WebGL exists in a stable deployment environment. Also, Microsoft (IE) who still has a large part of the web browser market still has not decided if they will support WebGL in their browser, of if they will stay on the plug-in path with a proprietary solution, competing with Flash, et. al.

However, HTML5 is leveraging the web architecture, which provides technologies and lets the ecosystem decide how applications will be architectured between the client and the server. This is the strength of the web, the ability for the client(s) to collaborate with the server(s) and split where the data should be stored and processed for a given application, enabling content to always be up to date, and sometimes created on demand by the server. Because the server is visible to many clients, it also enables user interaction, made popular by social applications such as Facebook, twitter, etc.

 This concludes my 4 part blog post on The Promising Future for WebGL. I hope you enjoyed it. Please feel free to comment.

How to get involved

If you want to learn more about how to get involved making WebGL successful, check out the Khronos web site for all goings-on with WebGL.


Be Sociable, Share!


Leave a Reply

Your email address will not be published. Required fields are marked *