Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The thing is that chipset can play half life 2 just about alright.


The Source engine is much more mature and much better optimized than what's in WebGL implementations right now. Valve and other game makers have strong incentive to make their games run as well as possible on a wide variety of hardware. The WebGL implementations just haven't had the same kind of investment in time and expertise.


Writing a game engine is quite different to writing a set of bindings (which is basically all WebGL is). There isn't much scope for optimization so I wouldn't hold out hope for WebGL apps running much faster in future browsers.


Hm, sorry, I was under the impression the WebGL implementations were being done rather differently than they apparently are. I hadn't thought the calls were getting passed through directly due to security concerns.

Chrome, at least, appears to be a straight binding with extensive validation... That... kinda makes my nervous.


I think your nervousness is well founded, and that's why Microsoft won't implement WebGL [1], but Chrome's developers seem to think they can make things secure [2].

[1]: http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons...

[2] : http://games.greggman.com/game/webgl-security-and-microsoft-...


I don't think nervousness about a particular implementation approach is a reason not to implement WebGL, just a reason not to do it in what I gather is Chrome's way.

On the other hand, Chrome's strategy might just be getting explained poorly. My nervousness comes partly because the way it's described sounds like a filtering strategy. If it's more like a whitelisting strategy, it could be considerably less scary, and more in line with what I was kind of expecting from browser vendors.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: