How Far is the Reach of WebGL on the Desktop

Posted on April 15, 2013 | 4 comments


WebGL is definitely making some great in-roads into desktop browsers. There are a lot of other HTML5 features that round out WebGL for games, for example check out some AAA web demos here. In talking to people there seems to be some confusion about what is the real reach vs all the hype. Of course WebGL keeps changing fast, one of the reasons for all the hype, but I wanted to talk about the current technical landscape of WebGL.


WebGL is not a W3C specification, it is driven by the Khronos Group. Here is a blurb from their site:

WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as Document Object Model interfaces. Developers familiar with OpenGL ES 2.0 will recognize WebGL as a Shader-based API using GLSL, with constructs that are semantically similar to those of the underlying OpenGL ES 2.0 API. It stays very close to the OpenGL ES 2.0 specification, with some concessions made for what developers expect out of memory-managed languages such as JavaScript.

WebGL brings plugin-free 3D to the web, implemented right into the browser. Major browser vendors Apple (Safari), Google (Chrome), Mozilla (Firefox), and Opera (Opera) are members of the WebGL Working Group.

If you have noticed there is one major browser vendor missing from the list, Microsoft (Internet Explorer). That might change (rumors) in the future with IE11. But this doesn’t address IE browsers before version 11.

Ok, so in the real world what browsers have WebGL? The latest Chrome and Firefox enable it by default. Safari and Opera require steps to enable WebGL. IE does not support WebGL in its current form.

Don’t forget GPUs

Even if all the browser vendors supported WebGL fully out of the box there are other factors that affect reach. The biggest one being graphic drivers. A good comprehensive list of driver support can be found on the khronos WebGL wiki page. For various stability and security reasons WebGL implementations use blacklists and whitelists to determine what GPU drivers are allowed to be used. For example Chrome uses a certain set of drivers on Windows that are newer than 2009, but Firefox currently only does drivers newer than 2010. WebGL driver support will change over time; the Stage3D API implements driver support back to 2006 (Intel GMA 2005 drivers with constrained mode). There are other considerations as well. The older chipsets have the potential for the GPU hardware itself to not support the entire WebGL specification. This is especially true for the newer WebGL specs, like the WebGL OpenGL ES 3.0 specification that will drive WebGL in the future.

What does this mean in the real world? It’s hard to give definitive numbers since WebGL is changing in the browser and graphic drivers areas. I can give highly subjective numbers based on companies that have implemented Stage3D APIs with live web content that can give you a rough idea. With Stage3D the browser reach factor is not there, as it was implemented across all browsers on Mac, Windows, and Linux support. That means just taking into consideration the GPU driver reach factor the dev is left with the following tidbits. For Stage3D content that was limited to drivers released after 2009 saw about 60%-70% of the users able to play the content. Going back to later than 2008 the reach jumped up to 70%-85%. Going back to later than 2006 and support certain Intel GMA chipset with a constrained mode allowed content developers to reach 90%+ (usually 94%-96% is best possible regardless of technology) of their users.

Or here is a thread for a specific test inside a legacy app to see Stage3D’s reach.

There is a site that is a rough indication of where WebGL is right now called The site also breaks down specific API availability that relates to WebGL or content commonly used with WebGL.

This is where WebGL is headed. In this process of moving forward it is good to learn who can really be reached with the newer tech and why they can or can’t be reached. There are a slew of error messages when drivers don’t work but that needs some work too.When content doesn’t work, it is good to know if the root cause is lack of support, a blacklisted driver, no GPU, or some other specific error rather than simply knowing the WebGL API call failed.

On a very technical note, this is a great article that talks about portable code from a GPU hardware issue perspective.

What about Mobile?

WebGL on mobile is making inroads with Chrome and Firefox on Android. The nice thing about the mobile industry is the devices are all new or hardware changes faster. And that means there are newer GPUs and drivers on these devices. There will be less of a graphics driver reach issue for mobile, but there is always the possibility of bad driver support or OS lack of API interfaces. Then it is a matter of getting more OS/browser support to drive the mobile reach.

Comments and Future Changes

Please share your thoughts about graphic driver reach and other factors that prevent end users from being able to use WebGL. There will definitely be changes in the areas above as time progresses.