I don't agree. The sorts of games that are microsoft-exclusive are mostly big-name high-performance titles, not the sort of casual free-to-play minimal-intensity stuff that's possible with HTML5. Javascript is nowhere near performant enough to be suitable for AAA development, and plenty of casual titles are often ported to multiplatform more reliably via flash / unity or similar.
It's not the lack of WebGL that keeps studios developing primarily for Microsoft platforms; it's the ability to write low level, native code in high performance languages, the ability to have as few layers inbetween game and hardware as possible. Writing native, you have hardware - os - api - game; if you're creating a high caliber performance-critical title such as, say, unreal, quake, starcraft, or half-life, why on earth would you choose to use hardware - os - api - browser - browser api - game?
WebGL is a cross-platform, royalty-free API used to create 3D graphics in a Web browser. Based on OpenGL ES 2.0, WebGL uses the OpenGL shading language, GLSL, and offers the familiarity of the standard OpenGL API.
WebGL is a low-level API, so it's not for the faint of heart. OpenGL's shading language, GLSL, is itself an entire programming environment.
Quake 3 was released in 1999, 13 years ago. It ran well on my 700mhz Pentium 3, with a 32mb TNT2 graphics card.
Show me a WebGL demo with the level of realtime visual fidelity and physics simulation from a game five years old - say, Crysis - and then I'll believe that WebGL is suitable for game development.
This particular conversation is precisely about AAA titles dominating on Windows.
Otherwise, the web is becoming a more viable target for small and indie devs. But as another commentator pointed out, without a overhaul in how video driver developers approach their work, WebGL as a concept cannot be made secure. Either browser vendors will wake up to this fact and at least start disabling WebGL by default, or enterprising black-hatters will start taking advantage of WebGL exploits, forcing browser vendors' hands.
High performance graphics on the web is a tough pickle :\
Apologies, I didn't realize this was just about AAA games, I saw Quake 3 in there... ;)
I don't think a major overhaul is necessary to make WebGL secure. There is really just one remaining issue, which is DOS attacks from slow shaders. This is not an issue on recent Windows releases which can almost seamlessly restart the GPU.
Aside from that, yes, there will be GPU driver exploits. There are also browser exploits and network stack exploits - we don't stop making browsers and network-connected applications though.
WebGL-ready browsers have very good capabilities to work around such exploits, either by simply blacklisting known bad drivers, or adding things like bounds checks to shaders etc. (which is currently done). Otherwise, exploits will happen and browsers will prevent them, just like browsers already do for non-WebGL content.
There aren't any serious WebGL attacks that have actually been demonstrated. Just a lot of FUD and some laughable Hollywood-style mock-ups designed to scare people.
On the other hand, there are many demonstrated usable attacks against Internet Explorer.
aboslutely - my team and I are close to finishing ours (shameless plug: http://www.jollycorpse.com), and I already mentioned Unity and Flash in my prior comment.
Though there's no way I'd write our 2D platformer using HTML5 due to absent gamepad support, a laughable audio engine, abysmal load times, and dodgy multiplayer capabilities, my original counterpoint was that WebGL support has absolutely nothing to do with developers' gravitation towards windows.
Are you saying that someone writing a -level renderer- that uses 35% cpu for a 13 year old video game means WebGL is ready for studio quality AAA titles?
It's not the lack of WebGL that keeps studios developing primarily for Microsoft platforms; it's the ability to write low level, native code in high performance languages, the ability to have as few layers inbetween game and hardware as possible. Writing native, you have hardware - os - api - game; if you're creating a high caliber performance-critical title such as, say, unreal, quake, starcraft, or half-life, why on earth would you choose to use hardware - os - api - browser - browser api - game?