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.

No more Google+ comments

I tried out the new Blogger Google+ comments for a while, but after experiencing some weird behavior (like comments not displaying on mobile) and hearing from a couple of people that avoided leaving comments because they didn't want a Google+ account I've decided to turn them off. This may cause a couple of comments to disappear, and I apologize for the inconvenience, but I'd rather have a reliable commenting system.

A Tale of two Web Technologies

Let's play a quick game: I'm going to describe a relatively recently announced web technology, and I want you to guess what it is.

• It was developed by a generally well respected company that focuses on moving the web forward.
• It was started to enable the web to move beyond the inherent limitations of javascript.
• It allows developers to run applications programmed in a language other than javascript.
• The company behind it encouraged others to join in its development, and has actively been improving it themselves.
• It was designed so that when run in a specialized VM it could run much faster than an equivalent Javascript app.
• To preserve backwards compatibility, however, the code is cross-compiled into standard javascript, allowing it to run on most modern browsers.

So if I stop there, what's your guess? If you've been keeping up with these things I bet you're probably thinking asm.js, which is a good guess because it meets all the criteria up above. Let me add one more hint, though:

• When announced this technology was regarded with skepticism and vocal opposition.

Ah, that makes a difference. What's your guess now?

"What is Dart, Alex?"

Bingo! We have a winner!

WebGL Draft Extensions in Chrome

I mentioned this was coming in my last post, but it's a significant enough change that it's worth addressing on it's own. New Chrome builds, starting with today's Canary build, will begin including a new option in about:flags called "Enable WebGL draft extensions"

(This can also be activated via the command line with the --enable-webgl-draft-extensions flag)

When you enable this it will allow WebGL to access extensions that Chrome has implemented but are still in draft status on the WebGL Extension Registry. Previously these extensions would have been exposed without the flag, but with a "WEBKIT_" prefix. That goes against Blink's policy of avoiding vendor prefixes wherever possible, however, hence the new flag.

The only extension this flag exposes currently is the newly implemented EXT_frag_depth, and any extensions that you previously queried using a prefix will continue to work just fine. 

So what does this mean for you, daring WebGL developers? 

How Blink has affected WebGL?

One of the topics that was suggested when I recently took a poll on Twitter/G+ of potential blogging topics was what kind of impact the switch to Blink has had on Chrome's WebGL implementation. I thought this would be a great area to talk about, because it allows me to dig into the guts of how WebGL works a bit more than most of you are used to.

If you're not familiar with the situation already, Chrome recently switched rendering engines from WebKit to Blink, which is based off the WebKit source. The fact that we're so early in the life of Blink means that the two rendering engines haven't diverged too much yet, aside from dead-code cleanup on both ends, but even this early there are a few changes in how Chrome handles WebGL.

How Microsoft could possibly, just maybe, become WebGL's biggest supporter

Ready to jump head-first into wild speculation land? Come on, it'll be fun!

It occurred to me today that there's a slim possibility that in the near future Microsoft may actually become the biggest driver of WebGL adoption in the industry. Yes, that's right, "WebGL considered harmful" Microsoft. Sounds crazy (probably is crazy) but I feel the possibility is definitely non-zero. Why? Let's string together a series of massive assumptions, shall we?

Welcome to the Next Gen™ (Same as the Last Gen, but better lit)

So footage for the next installment in the "Battlefield" series was posted today, and it's got a lot of people excited. For good reason too, it's gorgeous! Totally worth your time to watch the full 17min preview:

Much respect goes out to the engine developers and artists, those are some pretty pixels!

Too bad the gameplay doesn't look like it got a similar overhaul. This is basically the same game we've been playing since Call of Duty: Modern Warfare in a new coat of paint.

For starters the enemy AI looks pretty braindead. They can't seem to aim, don't notice people running around 3 feet behind them, tend to stand in open "scope-approved" places, and don't really move around much. Yawn.

But that's okay, because the real point of playing a game like this is to be shuffled from one tightly scripted, minimally interactive set piece to the next. Right? Of course at some point that stops becoming a game, and that's what's got me a little down.

It's very interesting that this preview starts out showing us the ending, then bounces back in time to show how we got there. Flashbacks can be a very effective literary technique, but in the context of a game it carries some unwelcome subtext: "Nothing you do over the next hour matters, because you will always end up right here." And why not? After all, the animators spent a lot of time on that scene, the artists custom built an "upside down car underwater set" just for the occasion, the script writers agonized about the precise placement of all those swear words to convey the appropriate panic with a "mature" feel. There was a lot of blood, sweat, and tears (and money) that went into that 5 minutes of barely interactive cutscene, it would be a tragedy if the players missed it!

And as a result no matter what you do you're going to end up upside down in a car underwater. You'll never be able to outrun that helicopter, you'll never be able to save Soldier 3's leg, never be able to successfully defend the pickup point, and never spare your helicopter support her untimely end. What you can do (the "interactive" part) is fail to live long enough to witness yourself failing to do all these things. Did someone order a side of fatalism with their escapist hobby?

Maybe it's just me, but I was hoping that the next generation of game consoles would let us get away from these kinds of on-rails experiences. And yes, maybe that would mean that some game designers would have to give up on their secret Hollywood aspirations, but I'd have a lot more fun with the end result. I'm not saying games can't have a well-written narrative, but I'd really like to play a more active role in shaping it. By all means, have the helicopter pilot radio in and say "Extraction point is that building, go!" And then let me figure out how to get there. Sure, throw the enemy chopper at me right before I escape. But rather than forcing me into some pre-scripted "hanging off the building" scene, let me ACTUALLY defend the building! Wouldn't be awesome to be ducking around that shell of a structure, desperately trying to get pot-shots off, while the helicopter systematically rips the building to shreds around you? And if I or my teammates die in the process, so be it. It will be far more meaningful to me if I knew I could have saved them, rather than knowing that they're doomed from the start.

And hey, go ahead and keep that whole underwater car thing in there! There's a decent chance I'll be forced off the road anyway while swerving to avoid the hellfire raining down above me. It would be extra cool to know that the developers planned for that and didn't just throw up a "game over" screen when the car hit the water. But let me actually escape sometimes too!

Emergent gameplay is a tricky thing, because by necessity it's not going to be nearly as consistently intense as a carefully curated experience (though our increasing technological capabilities allow it to be more interesting). The times where it all comes together just right, though, are the moments that we as gamers remember forever. Those are the moments that we post to YouTube and rave about in forums. Those are the moments we share with friends the next day with giddy excitement. Rather than "Hey, have you reached the helicopter scene yet?" "Yeah! That was awesome!", which is a great reaction in it's own right, it becomes something personal, but with just enough shared context that everyone can relate:

"Hey, so you know that helicopter scene? So get this, I'm trying to fight it back but right before I fire my RPG the building supports get shot out and the whole floor starts to topple over! My shot goes wide, and I'm trying not to fall while desks and boxes and stuff are sliding past me. Then the chopper swings back around and I think I'm toast, but the RPG that I fired earlier hit that smoke stack off to the side, and it fell down right on top of him right as he began to fire! I had 8 health left! It was incredible! And so then I..."

Sources of Motivation

I, like many other developers I'm sure, seem to go through mini "burn out" cycles every N months and hit slumps where I don't seem to be making progress on any of my personal projects and thus have a really hard time sitting down at a keyboard and punching out some code.

Image swiped from Kotaku 'cause I think it's pretty!

(I can usually keep myself productive at work, but that's because "keeping a roof over my family's head, food on their plates, and clothes on their back" is a mighty powerful motivator! It's far easier to let the hobby stuff slide, though, even when that's usually the more interesting work.)

Though I'm not in one of those slumps right now (unless you consider "my child takes up a lot of what was previously free time" a slump) I got thinking the other day about how I always get incredibly motivated to create something great after hearing about other people's success stories. I have been lifted out of my funks before simply by reading a single article or listening to a single talk. And that got me thinking that if it works for me then why not share some of my favorite sources of inspiration and motivation with the good readers of my blog? Maybe it'll help one or two of you get motivated as well!

Thus, without further ado I give you: Toji's "Recommended reading and/or viewing list for programmers that need to be motivated to code good and do other things good too."
// TODO: Work on better article name generation skills

Recommended reading - Debugging a Resource Leak in WebKit

My colleague at Google, Ken Russell,  has just posted a very in-depth recounting of how he tracked down a fairly tricky WebGL bug in Chrome's WebKit port after I had identified that creation of Web Workers was causing WebGL resources (and a lot of other resources too!) to leak. It's a very technical read that involves lots of C++, gdb, and stack traces but if that's the kind of thing you're into it's a pretty interesting tale. Take a look!

Graphics Prose - Debugging a Resource Leak in WebKit

Get WebGL working on the Android Chrome Beta

[UPDATE: This whole process just got a lot easier! With the newest update you can now visit about:flags (or chrome://flags, take your pick) and click the link that says "Enable WebGL". Then restart the browser and you're done! Best of all? No root required!]

Today a new Chrome Beta was released to the Google Play store. While the current stable Chrome release is based on the relatively old and crusty Chrome 18, the beta is based on the Chrome 25 code base. It's a big step forward in a lot of aspects, but there's one very specific capability that was added that's of interest to readers of this blog: WebGL support!

Now don't get too excited, because it's not turned on out of the box and not everyone will be able to enable it, but if you're interested in doing some early testing of your WebGL app(s) it's now possible with a little bit of tinkering.

glMatrix 2.0 Released!

Hey, did you hear that it's a 2013 now? New years usually inspire resolutions, and one of mine is simple: Finish more of the projects that I start! To get off on the right foot in that regard, lets start off the year with a brand shiny new glMatrix 2.0!

So what's new in version 2?

• The entire API has been reworked with an eye towards consistency and speed. This means that while it looks similar to the previous revision the new library is NOT backwards compatible with glMatrix 1.3.7. That's an unfortunate casualty of progress, but a necessary one to make sure the library isn't held back by mistakes made early on.
• A much expanded suite of unit tests. We don't have full test coverage yet, but the new tests should at least help to ensure that we catch obvious regressions before they make it into the wild, and it can be expanded to cover new bugs as we find them
• A new library structure and build process that integrates the new tests and will eventually make new releases a one-click operation.
• More optimizations!
• New functions at the request of the community!
• A higher version number!

This new version has been in the works for a little while, and there's still some more updates that I'm planning on around the documentation and landing page, but I'm pretty happy with where the code is at, and the new version should allow the library to evolve more smoothly as feature requests and bug fixes roll in moving forward.

Of course, the new release isn't something that I can take credit for alone. There's plenty of thanks to go around to everyone that's contributed code, ideas, or even just opinions to get the library where it is now. In particular, thank you to:

• Nicholas Kinsey
• Samuel Williams
• gero3
• jagenjo
• Juriy
• Kevin Reid
• Sam Howie
• Won Chun
• Ben Vanik
• Warren Hunt (who really needs some sort of linkable page!)

And of course, glMatrix's co-author, who has been an invaluable source of support, feedback, and code: Colin MacKenzie IV (Otherwise known as sinisterchipmunk, which is the most awesome username ever!)

Happy new year, everyone, and happy coding!