WebGL: Frequently Asked Questions

From webglcookbook
Revision as of 15:01, 28 June 2010 by Giles (Talk | contribs)

Jump to: navigation, search

This is a list of frequently-asked questions about WebGL. It is not a tutorial -- if that's what you want, you can check out the Learning WebGL lessons.


Background and Getting Started

What is WebGL?

WebGL is a low-level JavaScript API giving you access to the power of a computer's graphics hardware from within scripts on web pages. It makes it possible to create 3D graphics that update in realtime, running in the browser. It's a web standard, so it doesn't need a plugin and will soon be available on many smartphones. Some people regard it as being part of the new 'HTML5' standard.

WebGL is managed by Khronos, an organisation which is responsible for a number of open standards.

How do I get WebGL running on my machine?

Right now, you need to install a special version of a web browser to use WebGL. You can get appropriate versions of Firefox, Chrome and Safari.

When will WebGL be ready for production use?

This is really three questions:

When will the WebGL specification get to version 1.0?

The WebGL Working Group have not announced a date, though they are very positive about how rapidly they are approaching a final version. Usefully, some of their deliberations happen on a public email list, so if you want to get a good feel for that current state, a good way to find out is to read the archives.

When will WebGL be available in the standard versions of web browsers?

Hopefully soon after the specification reaches 1.0! There are "pre-alpha" testing implementations in three of the major browsers, and because these implementations are following the specification as it evolves, so while the author of this FAQ can't make promises on behalf of the browser development teams, it doesn't look as if there will be much of a delay once the specification is ready.

When will enough people have WebGL in their browsers to make it work using on a website?

Naturally, this depends on the kinds of people who visit the site -- which browsers they use and how frequently they update them.

People who use Microsoft Internet Explorer will have specific problems with WebGL: as of this writing, Microsoft have not announced any intention of supporting it, so IE users will be reliant on a plugin. More about this in [#What about Microsoft?]

For users of Chrome and Firefox, there is interesting information about how rapidly they have upgraded to new versions in the past in this blog post. The short version: Chrome users will be automatically upgraded within a month or so of a new version's release; the Firefox upgrade will be slower to a greater or lesser extent depending on whether they package it as a major (eg. 4.0) or minor (3.7) release. Safari will be somewhere in between.

What about Microsoft?

As of this writing, Microsoft have not announced any intention of supporting WebGL, and their press announcements surrounding their new version of Internet Explorer, version 9, have said a lot about its use of computers' graphics hardware as a way of speeding up existing web pages, instead of doing new stuff like WebGL. So while they've not said explicitly that they're going to avoid WebGL, it seems unlikely that they're going to support it in the short term.

(It should be said that while it would be consistent with their popular image for them to launch their own competing non-open system for hardware-accelerated 3D graphics, they have shown no signs of intending to do that either.)

What this means for now is that Internet Explorer users who want to see WebGL content will not be able to in the standard version of their browser. However, there may well be a way to work around this; Chrome Frame is a plugin for Internet Explorer which takes over the rendering of a particular tab, doing it using Chrome instead of the normal IE rendering engine. With an appropriate bit of JavaScript trickery, you can set up a web page so that when IE loads it, it will tell the user that the Chrome Frame plugin is needed to view it. That's not an ideal solution, but it's better than nothing.


Why is coding WebGL so hard?

WebGL is a low-level API. That means that it is designed to give you access from JavaScript to as much of the power of the user's graphics hardware as is possible with being possible to run on a broad spectrum of devices -- from PCs with Nvidia or ATI graphics, all the way to smartphones -- and with security, with the minimum number of functions and data types.

In particular, it inherits from OpenGL ES 2.0 (the cut-down graphics for mobile devices on which it was based) a purely programmable pipeline, with no fixed function support. To put that in a less technical way -- graphics libraries like older versions of OpenGL have a plethora of useful functions which beginners can use to get started with, but experts rarely (if ever) use. Getting rid of the beginner-friendly functions makes the system smaller and "simpler" in a sense, which is a good thing when you need to use it on a cut-down device like a smartphone, but does of course mean that it's a bit tricky to get started with it.

However, there's good news. If you don't want to go to all the effort of learning the low-level API, you can choose a high-level one instead. The fact that WebGL provides a solid framework that can be guaranteed to run on any compatible device means that many developers have worked hard to produce frameworks that make programming it easy.

But isn't JavaScript too slow?

The JavaScript engines built into browsers are getting ever faster, but yes -- for some kinds of calculations, particularly numerically intensive stuff, JavaScript is too slow right now. For example, you probably wouldn't want to write the physics engine of a modern computer game in it!

If you want your WebGL pages to run quickly, you do have options:

* Try to push as much as possible into shaders.  Shader code is executed on the graphics card in parallel, and sometimes it can be surprising what you can do in it -- for example, picking objects in a scene and collision detection can both be done with appropriately-clever shaders.
* If latency isn't an issue move stuff back to the server.

Why can't I code my shaders in JavaScript?

WebGL code can look a bit funny, with the mixture of C-like shader code and JavaScript in one file. And understandably, it can feel a bit irritating to have to learn another programming language just to be able to draw 3D graphics.

However, at least in the short term, it's unlikely that you'll be able to write shaders in any language other than the specialised shader language, GLSL. This is because the processors on graphics cards, while extremely fast, are extremely simple. They can only operate on programs expressed in simple languages, and getting one to run a dynamic language like JavaScript would be well-nigh impossible -- and would probably wind up running much slower than it would on a regular CPU anyway.

What's the best WebGL book?

There are no WebGL-specific books right now. However, WebGL is based on OpenGL ES 2.0, and so books about that standard can be useful as guides so long as you're willing to do a bit of translation yourself:

Personal tools