Saturday, March 29, 2014

Oculus, Facebook, and the dreaded "Ecosystem"

It's taken me several days to get over my knee-jerk, emotional, Vader-esque "NOOOOO!!!" response regarding Facebook's purchase of Oculus. I wrote up a "Please cancel my DK2 pr-order" email immediately after hearing the news, but resisted hitting the send button because I knew that anything I did at that point would be out of spite and not because I truly no longer believed in the product. Now that I've had some time to think on the matter, though, I feel like I can actually enumerate my concerns pretty clearly.

Friday, February 21, 2014

Xbox One controller in Chrome on OSX

I've been working lately on better Gamepad API support in Chrome (call it my "20% project"). It's been a fun change of pace from WebGL, primarily because it's much more straightforward code. In the process of learning the ropes, I decided to try something a little crazy: I noticed that our code path for supporting the 360 controller on OSX didn't rely on any drivers, but instead used IOKit to parse the data packets manually. (Check out that code here.) So I figured, hey! Why not try the same thing with the Xbox One controller, ignoring the fact that it's currently supported on exactly zero non-console platforms.

Somewhat unexpectedly, it really wasn't too hard!


Monday, February 17, 2014

How Blink has affected WebGL, Part 2

In a previous post I detailed some of the ways that the migration to Blink has affected the WebGL pipeline. The short version is that we were able to remove some layers of abstraction without changing the code which was executed, which cleaned up our dependency diagram a bit. At the time we ended up with a data flow that looked roughly like this:

That was 8 months ago, and I've been busy in the mean time! So let's take a quick peek at the current state of affairs.

Monday, December 2, 2013

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: ಠ_ಠ

Sunday, November 3, 2013

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.

Thursday, September 19, 2013

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

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.]