Making your WebGL code more flexible

The August update for Internet Explorer 11 includes new capabilities to help web developers detect when their WebGL application might encounter performance problems due to underlying hardware, including support for the failIfMajorPerformanceCaveat flag and WEBGL_debug_renderer_info extension. These can be added to other best practices to make your WebGL code more adaptable to the hardware that it is running on.

WebGL strategies for addressing hardware diversity

Web developers know that the world where we live is a complex one. The diversity of operating systems, hardware and browsers that our code can run on is huge. For example, to have your code work across diverse hardware means creating adaptable layouts or using graceful degradation. For a WebGL developer this means designing your code to run on high-end hardware that can render millions of triangles, or on a low-end device where 1000 triangles is the limit.

To allow your 3D scene to run on a small device, you can use some of these strategies to address this diversity:

  • Remove visual enhancements like shadows or particles
  • Reduce texture resolution
  • Reduce object complexity by using level of details
  • Change the resolution of your canvas and use hardware scaling
  • Reduce shader complexity (fewer lights, etc…)

Here’s how I handled these differences in the WorldMonger demo on the site:

Full version of WorldMonger demo

Here’s the full version, complete with shadows, reflection, refraction, and post-process effects. The following steps outline how I reduced the complexity to accommodate less powerful devices.


Step 1 – The post-process is disabled, particles are disabled, shadows are disabled, and the texture resolution is reduced for reflection and refraction

Step 1 – The post-process is disabled, particles are disabled, shadows are disabled, and the texture resolution is reduced for reflection and refraction


Step 2 – The hardware scaling is now 2x, meaning the canvas resolution is the screen resolution / 2

Step 2 – The hardware scaling is now 2x, meaning the canvas resolution is the screen resolution / 2


Step 3 – The hardware scaling is now 4x and texture resolution is reduced again for reflection and refraction

Step 3 – The hardware scaling is now 4x and texture resolution is reduced again for reflection and refraction


To be able to apply these strategies to reduce scene complexity, you must figure out if the current device is powerful enough or not. To do so, let’s see together different options you have.


The obvious option is benchmarking. One way is to render some scenes and measure the frames per second on a specific hardware to judge the overall performance. You can get more detail in an article I wrote about how to measure performance:

The main idea in measuring performance is to compute the delta in time between two frames. If the delta time is lower than a given threshold, then you can consider taking actions to reduce your overall rendering complexity.


Because of the direct access to the GPU allowed by WebGL, browsers must ensure that running your code will not cause a major security issue. For some specific drivers that are not perfectly secure, the browser can prevent hardware acceleration in order to prevent security issues.

To enforce this, IE has a block-list of drivers that are not safe for use with hardware acceleration. On these devices, WebGL will software rendering instead, resulting in a slower but safer experience.

In the August update of Internet Explorer, we support a new flag that you can specify when getting your WebGL context: failIfMajorPerformanceCaveat.

The Khronos specification defines how this attribute works:

Context creation will fail if the implementation determines that the performance of the created WebGL context would be dramatically lower than that of a native application making equivalent OpenGL calls.

When a context is requested on a computer with a block-listed driver, the failIfMajorPerformanceCaveat flag prevents IE from returning a software context, and instead returns no context.

To use it you just have to add it as an option to the getContext function:

var canvas = document.getElementById('renderCanvas');
var context = canvas.getContext('webgl', 
failIfMajorPerformanceCaveat: true

Using this attribute, you can know that the current device isn’t powerful or secure enough to run hardware accelerated 3D rendering. Then you can decide to use the software renderer, or if you prefer, let the user know their computer or graphics card aren’t supported.

Identifying the renderer

Finally, in conjunction with the failIfMajorPerformanceCaveat attribute, IE also now supports the WEBGL_debug_renderer_info extension (Khronos specification).

The WEBGL_debug_renderer_info extension is a tool to get the renderer and vendor strings for the underlying graphics driver:

var gl = document.createElement('renderCanvas').getContext('experimental-webgl');
var extension = gl.getExtension('WEBGL_debug_renderer_info');
if (extension != undefined) {
    var renderer = gl.getParameter(extension.UNMASKED_RENDERER_WEBGL);
    console.log('UNMASKED_RENDERER_WEBGL = ' + renderer);
    var vendor = gl.getParameter(extension.UNMASKED_VENDOR_WEBGL);
    console.log('UNMASKED_VENDOR_WEBGL = ' + vendor);

For instance, here is the result I get on one of my computers:


You can use this information to gather useful information for debugging; for example, if you detect using benchmarking that your code is running slowly, then you will be able to gather data for reproducing the issue.

But beware: Like user agent sniffing, using this feature to create a GPU “approved list” could result in a lot of other devices not being able to experience the best your app has to offer. Instead, I recommend targeting the broader audience by using it to only block specific devices that you’ve identified to perform poorly with your app.


Being able to create WebGL experiences that works seamlessly in all kinds of configurations is extremely hard. However, you can use these tools to have more control over the device and give more feedback to your users.

We will be sharing more details about WebGL support in the latest version of IE11 soon. In the meantime, we look forward to your feedback @IEDevChat or on Connect.

— David Catuhe, Principal Program Manager, Internet Explorer

Comments (12)

  1. Nacimota says:

    In last month's AMA on reddit, it was explained that poor WebGL performance on some software/hardware configurations was due to IE falling back to software mode for security reasons:

    "On some older NVidia & some (Windows 7) AMD GPUs we render WebGL in software rendering mode for security reasons; you might be on a system where IE is rendering WebGL content in software rendering mode. (Take a look at the F12 console; it'll say in there.)"

    I'm using an AMD Radeon 7970 on Windows 7 and WebGL doesn't work (more specifically, it does not appear to be GPU accelerated) for me in IE11 (presumably for this reason). Is any progress being made towards this issue?

  2. Mark says:

    I'm pretty sure this isn't something they can help with… What I'm willing to bet is going on (while I don't actually have inside knowledge, I'd be willing to bet good money) is that the ATI/NVidia drivers are just assuming they're getting good input, and not validating it properly. That means that if a malicious party uses a particular type of malformed code, the drivers probably don't handle it properly and you get remote code execution by just visiting a site.

    In order to fix this, AMD/NVidia would need to fix their drivers for older cards, and why would they do that when they can just sell you a new card?

  3. Yuhong Bao says:

    @Mark: Radeon 7970 is not particularly old though.

  4. PhistucK says:

    What about the increasing fingerprinting factor that this extension provides?

  5. hAl says:

    When will IE start with support for h.265 video codec in html5 tag.

  6. @hAl says:

    There are so many issues with media in Microsoft stack.

    To begin with..

    They screwed up support for their own codecs and video containers on their own platforms (such as Windows Phone and Internet Explorer for Widows Phone). See…/cisco-2500-ipc-streaming-in-windows-phone-8. ASF is Microsoft's own container for live-streaming since ages! But yet they made it impossible to make the implementation easy for developers on Windows Phone. Android and iOS worked like a charm for this project (even their native browsers were able to run the ASF live steams, while Windows Phone's IE gave error message "Your phone doesn't support this video format".

    WTH is this? I mean world is moving forward and Microsoft is going with reverse gear! Even Windows Mobile OS (predecessor to Windows Phone OS) used to support this live-stream format.

    The solution I got form Microsoft engineers was to configure IIS smooth streaming.. which is another hassle (but I tried to configure it in haste, as I was on a short deadline and it didn't worked). Other OSes were able to run the streams directly as well as VLC as a streaming server..

    Media department at Microsoft SUX BIG TIME! So I had to provide crappy experience for Windows Phone users (the laggy JPEG streaming.. I still regret figuring out that limitation of Windows Phone.. ignorance is bliss I guess :S)

    — this was one and a half year ago, and I don't have that code now or access to that CISCO CCTV, but I am willing to make a bet that Microsoft still not give a c-rap about that in their latest preview WP 8.1.1..

  7. @@hAl says:

    Maybe Microsoft does not understand that consuming media is the #1 thing that people do on the internet.

    Who cares about WebGL

  8. ahmet says:

    .They talk about it a lot, yeah, I'm

  9. Den says:

    Could you please provide details whether XNA 5 will support compiling to Asm.js and use Web GL? Thank you!

    Any details on your collaboration with MonoGame developers would also be appreciated.

    XNA 5 is a top request by users:…/3725445-xna-5

  10. Mark says:

    Is there a way to temporarily disable the GPU blacklist for webgl?

  11. Ben Adams says:

    @Nacimota also some of the GPU manufactures have issues where they force the browsers to use the GPU on the CPU rather than the gfx card so you will get decreased performance see here:…/optimus which is also why the unmasked renderer is important to know

  12. Karma says:

    @Ben Adams, your link says that IE doesn't support unmasked. This blog post contradicts it. So when people say web developers are bunch of fkin liars spreading FUD, they aren't wrong eh?