WebGL on IE11: welcomed but unfinished

Last week Microsoft released a preview of Windows 8.1 including a version of Internet Explorer 11 supporting WebGL. This is great news from Microsoft and immediately downloaded and installed the preview version in order to test the game engine running on IE11. Once the installation was complete the first thing we ran was the device initialization sample, and we got a couple of errors on the Console:

Not a great start, but lets look at the stats reported by the WebGL device:

The interesting bit is what is missing from the bottom, after “Extensions:”. Disappointingly IE11 does not support any WebGL extensions yet. This is unfortunate because some of them, for example the ones that provide support for compressed textures, are fundamental to reducing memory usage and improving performance.

Anyway, we pressed on and tried one of the less graphically demanding examples:

image

You may notice something missing, those cubes are supposed to have a nice crate texture on each face! There are a few reasons they don’t:

1. One of the errors reported by the console is “vertexAttribPointer: Enum SHORT is not currently supported”, you can see it at the bottom of the first image.

This particular example is storing the UV coordinates used for the texture as two 16 bit integers, the values are just 0 and 1 so using integers is a perfectly valid way of saving memory, the alternative is to use two 32 bit floating point values which would double the storage requirements for each UV component. This is not a big deal for a simple cube, but can become a more serious issue for big models. Reducing memory requirements is very important for games, even more so if your game is running on a browser on a mobile platform, so being able to use smaller vertex formats is a requirement for us.

2. Another error reported by the console is “bindAttribLocation: Method not currently supported”, you can see it in the middle of the first image.

Turbulenz relies heavily on using bindAttribLocation to assign vertex components from vertex buffers to their relevant input attribute on the vertex shader. We could use getAttribLocation to ask the vertex shader where it wants its inputs, but this would require late binding of vertex buffers and the update of attribute locations if the shader changes. So instead the Turbulenz engine uses bindAttribLocation to tell the shader where to get its inputs from, which allows us to bind the vertex buffer immediately and to only have to bind it once. This is important because the Turbulenz engine creates large vertex buffers that are shared between several static geometries, independent of whatever rendering technique they use, allowing us to avoid the memory overhead of creating multiple buffers and also reducing the number of state changes. This is part of what makes Turbulenz such a high-performance rendering engine.

Continuing with our experiments we tried the sample app, which is just a rotating duck, and got nothing on the screen. Why? Well, there were more errors reported on the console:

The first error reported is “bufferSubData: Method not currently supported”. The lack of support for this method is significant. As explained earlier, the Turbulenz game engine shares big vertex buffers between several static geometries in order to avoid memory overhead and state changes. In order to do that, vertex information needs to be submitted independently for each model using the method bufferSubData. One alternative would be to keep sharing but to upload all the vertex information at once, but this requires us to hold all the geometry in memory longer than we would like and is also not practical if the game is streaming in and out static geometry. The other alternative requires creating an individual vertex buffer per geometry, which is not acceptable because it will increase buffer overhead and require more state changes.

The other problem we hit with this sample was:

image

It seems the WebGL implementation on IE11 does not understand GLSL shaders with structure declarations - a perfectly valid language feature that is supported in other browsers. The only reason the first example we tried rendered anything to the screen was because we don’t always use structure declarations in our shaders, for simple programs it is just quicker to declare the varying values independently. Admittedly we were considering removing structure declarations from our shaders because they make the shader code bigger (a concern for us as we try to seriously reduce the amount of data a game needs to download in order to render anything on the screen) so we may rewrite our shaders to work with this version of IE11.

There were more things failing on other examples: triangle fan primitives are not supported, luminance only texture formats are not supported, full stencil support is missing, etc. And, we reproduced the same issues on different machines with different video cards from different manufactures.

Are we going to change our code to workaround the missing WebGL features on IE11? Not whilst it is in development and only a preview.

Some of the workarounds will require substantial changes to the engine, and they may impact performance significantly. This version of IE is clearly not final yet, and we’re keen to help Microsoft deliver a fully compliant implementation of WebGL that would make Internet Explorer 11 competitive with Google’s Chrome and Mozilla’s Firefox. Exciting times for WebGL and HTML5.