Post is preserved here simply for the sake of mocking my (lack of) predictive powers.]
This may come as a surprise to some of you, but I'm rather fond of WebGL. :) And if you've been following some of my demos you'll probably notice that they tend to have a somewhat game-oriented tilt to them. This is fairly natural for me, since I'm both a gamer and a programmer. It's two passions in one sweet package, kinda like a Reeses Peanut Butter cup.
Anyway, I'm a firm believer that as it matures WebGL will play a big part in game development, just as the web has already altered the game industry. I doubt that we'll ever reach a point that browser based games take over entirely, but they're going to keep getting bigger and better and the lines between desktop and browser games are going to blur. Some people will embrace this, some will fight it, and if nothing else it will be an interesting ride for everyone involved.
There are some key limitations, however, that need to be overcome before WebGL (and the browser as a whole) can really truly be considered a full fledged, general purpose gaming platform. And those issues are going to be hard to solve. Incredibly hard, for both technical and theological reasons. So hard, in fact, I'm not sure that the minds behind the web today are able to fix them, or even that they want to. In fact, I'm not convinced that they should.
Before we jump into that, though, I want to talk about some perceived "issues" that I've seen cropping up frequently around the web. There are a myriad of reasons people don't think WebGL will work out, and most of them are either very shortsighted or downright wrong.
Please keep in mind that I'm talking mostly about 3D gaming here, since I think just about any other application of WebGL (ie: medical imaging, mapping, architecture, education, data visualization, etc.) will succeed practically without trying. Gaming stands alone in how demanding it can be on the average users system, and thus is concerned about factors that many other applications aren't. That being the case it's easy to see why people might have their doubts, but in my opinion the following problems aren't going to be very problematic in the long run:
Microsoft
It seems that any time people start talking up WebGL there's at least one guy in the crowd that has to throw in: "Yeah, that's cool and all. But Microsoft is going to do their own thing and everyone will just use that, so WebGL won't really matter." This is so painfully narrow minded that it physically hurts me to hear otherwise intelligent people say it.
Let's look at the known facts on this one: Microsoft has yet to announce support of any browser-based 3D API for IE9, WebGL or their otherwise. And... that's about it! They've been pretty tight lipped on the subject. We do know is that Microsoft is pushing very hard for a standards based, HTML5 oriented browser with their next revision. We know that they will be including items like Canvas, Video, and Audio tags, vastly improved CSS support, and a host of other happy things that have nothing to do with promoting a closed Microsoft ecosystem. Given that, it would actually seem quite out of place for them to about-face and try pushing a Windows-specific "DirectWeb". If anything my impression is that they're waiting for WebGL to mature and prove itself a bit more before announcing support (since WebGL is still a very young and experimental tech.)
But let's look at the different scenarios and their likely fallout anyway, just for kicks:
- Microsoft supports WebGL - Yay! And there was much rejoicing!
- Microsoft doesn't support a 3D API at all - In this case someone will probably develop a plugin that allows IE to run WebGL content, or those individuals that want to use it will install Chrome Frame and be done with it. This still leaves WebGL as the defacto standard, though, so there's no reason not to code to it.
- Microsoft rejects WebGL and pushes a proprietary API - This is where things get more interesting. So now we have ~45% of the web that can use WebGL and ~55% of the web that uses some other API. For starters, those are large enough numbers on both sides of the fence that no serious commercial venture would dare to ignore either of them, and you would probably see a lot of sites that can use both APIs depending on the browser, or simply use a wrapper layer or engine to hide the difference away. But wait! There's more! You see, those numbers aren't entirely accurate since they represent browsers as a whole, not browsers with 3D support. So let's look a bit closer:
(FYI: I'm looking at Wikipedia's entry for my numbers. Percentages can vary wildly depending on which stat counter you ask, but this one seems like it hits a good middle ground)
According to these stats, IE is used by a little over 50% of the market, but it's the breakdown of browser versions that we care about. IE6 weighs in at about 30%, IE7 around 21%, and the remainder is IE8, which means only about 50% of IE users are working with the latest version. Now when IE9 is introduced we can't expect every IE user to jump ship and start using it. I would imagine that most of those still on IE6 are there by company mandate, not by choice, so that number will probably shift very little. People on IE7 obviously aren't in much of a hurry to upgrade either, so we can probably assume that number will fall pretty slowly too. IE8 users are going to be the most likely to upgrade, so best case scenario is that a little over 50% of all IE users make the move. But some of them won't be able to, since IE9 will be Vista/7 only. Digging for some stats there shows that only about 26% of Windows machines reported are running Vista or higher. But it's probably fair to say that people running these OSes are more of your early adopter types and are probably more likely to upgrade too, so that can skew the number of IE9 users a bit higher. Let's just be generous and presume that within a few months of release about a third of all IE users will be running IE9, OK? Great.
So now we're looking at 33% of 55% of the browser market share (~18%) that are using a browser with Microsoft's proprietary solution. And that's not even really taking into account mobile devices, which are becoming an ever more important part of the web ecosystem. Now, ask yourself: how much traction is that API really going to get? Thing is, I bet Microsoft has run the same numbers (probably far more accurately than I have here) and can see the same thing. I doubt they want to waste resources fighting that battle.
So when it comes right down to it, Microsoft can do whatever they want in regards to 3D online and I don't think it will change the situation significantly. WebGL is here to stay.
Javascript Performance
This is an argument that has a little more weight to it because it's undeniable that Javascript is slow. Yes, sorry Chrome, but even with your fancy V8 engine JS performance pales in comparison to native code. Asking an industry that is impossibly processing power hungry to accept huge performance hits on top-of-the-line hardware is a rough pill to swallow. There are a few points to keep in mind in this area though:
- We have proven time and time again that we don't need massive processors to create compelling experiences. Take the Nintendo DS, PSP, or iPhone for example. All are great pieces of hardware, but they all fall far short of a 360 or PS3 hardware wise, and are miles behind a high end PC. Yet gaming is alive and well on these devices. Surely if the game industry can produce AAA quality titles for these devices we can work with some less-than-blazing javascript performance.
- Web workers will go a long way towards allowing us to intelligently split up the workload. The trend towards multiprocessor development is well underway, and web workers have some of the cleanest, safest implementations of threading I've seen to date. This isn't anything unique to the web either, and we should be able to harness that power just as easily as anyone else. Probably better, actually, since your average web developer is forced to think asynchronously from day 1.
- There are some very large companies out there that stand to benefit greatly from making Javascript faster, and these same companies have the time, resources, talent, and motivation to make it happen. There's no question that performance will continue to get better as time goes on, and I'd be willing to bet that Moore's law will be in full effect here.
So yes, Javacript is slow, but it's continually getting faster, and we know we can work within those limits anyway. It's not going to stop anyone. Finally, WebGL does nothing to diminish the processing speed of your GPU. Once that draw call is made you're basically running at native speeds, and there are some positively jaw dropping things that can be done in shaders these days. So, is Crysis 3 going to be browser based? No. But I'm certain that we'll be amazed at what will be done with this tech, processing limitations and all.
Even ignoring Javascript, WebGL itself is slow!
This tends to be true right now, but not for the reasons many people would expect. In a traditional desktop 3D app there tends to be two places that things get bottlenecked: You're either CPU limited, where the CPU is constantly running at 100% and the GPU is sitting around waiting for work to do or you are GPU limited, which is just the opposite. There are other things that can act as the limiting factor, but those are the big ones.
WebGL is similar, but with a few twists thrown in. For one, it's pretty difficult to become GPU limited in WebGL in a real-world scenario, since Javascript typically isn't capable of generating draw calls fast enough to overwhelm the GPU. It certainly is possible to become CPU limited if your script it too complex, and this may be the cause for the slowdown on some demos. We have a third bottleneck point here that's not present in your typical apps, though, and that's what I'll call "compositing limited".
In a web page all of the visual elements (text, divs, images, etc) need to be composited together to form the final page you see. It's kinda like working with layers in Photoshop. Some plugins like Flash can subvert this, since they're explicitly opaque (You can't see any of the page underneath them), but WebGL elements can mesh completely with other page elements, creating some really cool effects. There's a great demo highlighting this effect here. It's (in my opinion) one of the most powerful aspects of WebGL. That means, though, that a WebGL element has to synchronize it's display with the rest of the page, which can lead to some pretty sever limitations on display rates, especially for larger WebGL canvases.
The practical effect of this is that scenes which would otherwise be running at insanely high framerates are limited to 30-40 fps, which is not exactly awe inspiring performance. But it's not the Javascript or the rendering that's slowing it down, it's the process of embedding it in the page.
The fortunate part here is that there are individuals at Google and Mozilla right now working on this exact problem, and I have a lot of faith that they will solve it. Please keep in mind that WebGL is still in it's infancy and there are still some bugs to be worked out. This is one of them, and I fully expect that it will disappear in the future, especially as browsers move to hardware accelerated compositing.
Intel's OpenGL drivers suck
Yes. Yes they do. Actually, many Intel chips can't even run GL2.0 level shaders so it's a moot point. For the rest of them: ANGLE.
Okay, so if none of the above items are the problem, what is? The full answer is somewhat complex and multi-faceted, but it really comes down to one overarching theme:
Browsers don't want to ever take control away from the user
But that's a good thing, right? I mean, I WANT to be in control of my browsing experience. Well... yes and no.
Consider this: When was the last time you were playing a game that didn't allow you to directly control your mouse cursor? This is standard fare for pretty much any FPS or third-person action game. Moving the mouse is typically thought of as "looking around" or "aiming". In most of these cases you never even have a cursor, just a little permanently centered aiming reticle. Now consider your browser. How would you replicate that same type of control scheme? Short answer: You can't. (Not without some sort of plugin, but this is HTML 5, remember. We're trying to escape plugins, not require more of them.) Your browser simply doesn't have a built in mechanism for hiding the mouse or restricting it's movements. So now you've got a cursor flying around the screen while you play your in browser FPS, which means that if you fire your gun at the wrong time you've just closed your window, opened another app, deleted some program or shortcut... Bad Things© all around. In order to prevent this kind of inadvertent clicking the web app would have to take control of the mouse cursor away from the user for a little while, probably hiding it altogether until the user gives some sort of indication (like pressing escape) that they want it back, at which point they need to trust that the web app will actually respond to that request.
So now we should ask the big question: Should the browser allow for a page to take that kind of control of your system? Probably not, because anything that your game can do will also be available to any other website for any other purpose. That means every ad, scam, and phishing site would also have the ability to hijack your cursor at any time without your permission, and that's also a Bad Thing©. After all, would you trust a phishing site to give you back your mouse cursor when you asked it to? More to the point, do you want it to take it away in the first place?
And there we have our paradox. In order to allow for certain types of applications we have to implicitly take control away from the user, possibly to their detriment. But by taking away that control we lose a piece of what makes the web such an attractive thing in the first place. In a space as volatile and potentially malicious as the internet it is a perfectly reasonable choice on the part of the browser to say "Sorry, but I favor the user". But that puts some fairly severe constraints on what kind of games we can reasonably create inside a browser. And it's not just mouse control either, there's a myriad of different limitations like this. For example, while developing my Quake 2 demo I frequently and unconsciously found myself trying to "crouch" (move down) and forward at the same time (Ctrl+W). This was... frustrating to the say the least. We also don't have a true fullscreen mode, or access to gamepads, or the ability to use a webcam or microphone... the list goes on. All of these things seem perfectly reasonable in the context of a game and absolutely nightmarish when you consider giving that same capability to an online advertisement. Thus the biggest challenge WebGL faces as a gaming platform is getting the browser to let go enough that we can craft the experiences we want while still giving the user a safe environment to play in. No small feat.
So what can we actually do about it? Well, I would imagine that the first round of WebGL games that we see will either avoid these issues by design (a Diablo clone would work great, for instance) or will use a mixture of HTML 5 and plugins like Flash to achieve the desired effects. Sure, that breaks the "pure HTML" model that we all claim to love, but when it comes to creating a product most companies could care less about such idealism and will just go with what works. After that... who knows! Maybe there is a way that we can allow all of these things and still keep the user in control. If there is I certainly haven't thought of it, but I'm sure there are better minds than mine working on this and other problems right now. Until that time we're going to have to accept that there are trade-offs for working on the web, just as there always has been.
But maybe that's not such a bad thing either. Necessity is the mother of invention after all, and some of the most amazing advances of the digital age have come out of people working with the worst of limitations. Perhaps what we really need isn't more control but a different perspective, a new way of looking at things like gaming that we've never thought of before. Heaven knows that if there's anything the internet is good at it's crushing the old ways of doing things in favor of the new.
