Notch, WebGL, Dart, and ramping up quickly

Just a little something I thought was worth pointing out. @notch, the creator of Minecraft, has been posting updates on his latest toy project to his Twitter account recently. I've found this very interesting because he's doing a WebGL app in Dart, which just makes me all sorts of happy. Ignoring that, however his tweets illustrate something that I feel is very important.

failIfMajorPerformanceCaveat: With great blacklisting power comes the need for self restraint

Chrome is gaining a new WebGL context creation attribute: failIfMajorPerformanceCaveat. In the words of the spec, when you've set this useful little boolean to true:

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.

Essentially, if there's any reason why the browser feels that the requested WebGL context will have significant performance overhead setting this flag allows the browser to simply not give you a context. It's a way for you as the developer to say "This context needs to perform really well, and if you can't deliver that then I'd rather not get one at all." In Chrome's case specifically, there's only one reason we will currently fail to return a context and that's if the SwiftShader software renderer is being used. (We may add more cases in the future.)

I think the kneejerk reaction many developers will have upon learning about this is: "Hey! I always want my WebGL to run fast! I'm going to set this flag on every context I ever create forever!"

If that sounds like your thought process, I give a you a stern look of disapproval: ಠ_ಠ

Using WebGL on Chrome (AKA: "Why don't I have the WebGLs?!?")

It occurred to me the other day that although WebGL is now available on more devices with Chrome than ever before, Google actually hasn't said a whole lot about who has it, how to get it, and what to look for if you don't have it. Today I'm going to try and fix that!

The TL;DR version is that with some predictable exceptions most devices that run Chrome can get to WebGL at this point, and an increasing number of them have it turned on without any action on the part of the user. If you don't have WebGL on your device of choice it's most likely because we've explicitly identified problems with your hardware or your device hasn't implemented the appropriate safeguards, but in most cases you can still turn it on manually if you really want to.

At last! Chrome D3D11 day has come!

As of revision 223716, Chrome Canary will have the ability to use Direct3D 11 (via ANGLE) as the rendering backend! Woot woot! The new backend can be enabled using the "Enable D3D11" flag in about:flags. To tell which backend you are using visit about:gpu and look for the GL_RENDERER string.

That's cool, but should have no impact whatsoever on your day to day Chrome use (and if it does, we want to hear about it!) So why do I bring it up? Because along with the shiny new backend comes a much awaited WebGL feature: Multiple render targets! This extension has been available to Mac and Linux devs for a little while now (it's still behind the Draft Extensions flag), but had some spec issues that prevented it from being implemented in the ANGLE D3D9 backend. Now with the new D3D11-based backend the extension should be available to a much wider range of developers.

(Want to know if you have it? Look for "WEBGL_draw_buffers" in the supported extensions list on http://webglreport.com/)

So go, brave WebGL developers, and defer all your renderings for great justice!

[UPDATE: I initially said that the D3D11 backend may be enabled by default on some systems. Unfortunately that's not the case just yet, and I apologize for the error.]

What's coming in WebGL 2.0

The WebGL working group has just released a public draft of the WebGL 2.0 spec. Hooray! Of course, being a public draft things are still subject to change and there are still plenty of TODOs, so don't be too surprised if things get chopped, tweaked, added or completely reworked before WebGL 2.0 reaches a browser near you.

The nice thing is, however, that since the entire goal of the spec is to bring OpenGL ES 3.0 capabilities to the browser the chances of things deviating too much from that spec are pretty minimal, and it's probably safe to assume that most ES 3.0 features will make their way into your browser soon. (With a few notable exceptions that I'll discuss in a bit.)

So what is new in 2.0? I realize that reading specs is rarely fun, so allow me to summarize for you. While this won't be a complete rundown of the upcoming features it should provide a good sense of where things are headed.

Holistic WebGL

ho·lis·tic  

Adjective

Characterized by comprehension of the parts of something as intimately interconnected and explicable only by reference to the whole. Characterized by the treatment of the whole person, taking into account mental and social factors, rather than just the physical...

Definition from Google Search

As I've established way back on the very first post on this site, WebGL is awesome. So awesome that one might be tempted to start seeing opportunities everywhere around the web to throw some 3D goodness at it. After all: when your hammer is a 3D API, every problem looks like a vertex array... er, or something like that. Now never let it be said that I discouraged the use of WebGL, but as developers we should also be aware that every technology has a time and place.

What is holistic WebGL? It's application of the technology in a way that takes in to account the entire web experience, not just the content of your canvas tag. Holistic WebGL content is considerate about it's context and respectful of the user's time, attention, and battery life. In essence, it's the exact opposite of this:

Now I'm guessing that very few visitors to this site were actively working on "Punch the Polygonal Monkey" banner ads, but it's not hard to envision such a thing. After all, we all know that "eye catching" is an advertiser's friend. What's a poor ad designer to do now that their beloved Flash is being slowly smothered? Why, hellllooooo there HTML5! What lovely WebGL you have! And now we have pages where a deluge of banner ads all rendering beautifully shaded cars, watches, and pharmaceuticals makes your battery commit suicide, your fans squeal, and your page chug.

But wait! It doesn't have to be like that! WebGL can be used in a way that's both exciting and engaging while simultaneously being non-obtrusive and (crucially) non-rage-inducing. Much of it involves simply being aware of what place your WebGL content in the page as a whole.

WebGL instancing with ANGLE_instanced_arrays

And still no Shakespeare...

Ever find yourself in a position where you absolutely, positively have to get a ton of monkeys on screen with a single draw call?

Yeah, okay, me neither. (At least, not until I put together the demo for this post.)

But there's certainly occasions when it makes a lot of sense to redraw the same mesh many times with some minor tweak like position, orientation, color, etc. Simple examples of this are trees and other vegetation, streetlights,  boxes in a warehouse, soldiers in an army, and so on.

Traditionally with WebGL the optimal way to draw those repeated meshes, commonly referred to as instances, would be something like the following pseudocode:

bindMeshArrays(gl);
for (i = 0; i < meshInstances.length; i++) {
  var instance = meshInstances[i];
  gl.bindUniform3fv(meshPosition, instance.position);
  gl.bindUniform4fv(meshColor, instance.color);
  gl.drawElements(gl.TRIANGLES, indexCount, gl.UNSIGNED_SHORT, 0);
}

This is good, because we only set up the vertex attributes (implied to be in bindMeshArrays) once,  then make many draw calls in quick succession, only changing the properties that are different from instance to instance. In this case just position and color. This makes for a near minimal amount of overhead for each draw call, and in an environment like Javascript where each call is expensive that's important!

(This example is pretty simple, and in fact you can actually optimize it further by getting creative with how you provide the GPU with the data. Check out Gregg Tavares' wonderful Google I/O talk for more ideas about how to render lots of geometry very quickly.)

Even in this scenario, however, you have to make at least three WebGL calls for every instance of the mesh. That doesn't sound terrible but in the real world that would probably be quite a bit more, and the fact is that in Javascript every call into native code (Like the WebGL API) carries a certain expense. Thus while drawing repeated meshes in this way works, and generally works well, it could still be better.

And that's exactly why we have ANGLE_instanced_arrays.