Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Graphics Software Entertainment Games Technology

WebGL Standard To Bring 3D Acceleration To Browsers? 239

Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec, the Khronos Group has released a few details about their up and coming WebGL 3D acceleration standard. "The general principle behind WebGL is to offer a JavaScript binding to the group's OpenGL ES 2.0 system, allowing code run within the browser to access the graphics hardware directly in the same way as a standalone application can. As the technology would rely solely on JavaScript to do the heavy lifting, no browser plugin would be required — and it would be compatible with any browser which supports the scripting language alongside the HTML 5 'Canvas' element."
This discussion has been archived. No new comments can be posted.

WebGL Standard To Bring 3D Acceleration To Browsers?

Comments Filter:
  • Port 80 (Score:2, Insightful)

    by Anonymous Coward on Friday August 07, 2009 @06:27PM (#28991631)

    Does EVERYTHING need to be reinvented (poorly) on port 80? Really!!!???

  • by formfeed ( 703859 ) on Friday August 07, 2009 @06:34PM (#28991661)
    There goes the "fast enough for a little browsing and office apps"-computer. Yes, yes, I know, hardware acceleration will render the pages faster - but more and more sites will include 3d junk.

    Praise be to Moore and his irrefutable law:

    We are doomed to use faster and faster Computers and more and more energy, to read pages that might - content wise- just as well run on gopher.

  • Honestly? (Score:4, Insightful)

    by Iwanowitch ( 993961 ) on Friday August 07, 2009 @06:39PM (#28991705)

    I like this. Why not? It can be expected that web browsers use decent security practices, 3D drivers are already doing a fairly good job of providing a stable API via OpenGL, and everything is floating towards web browsers as new deployment platform, also for games and 3D applications. Better have an open 3D standard than a need of all sorts of plugins where everyone comes up with his own half-working solution. This is the indie game developer's wet dream coming true.

    Of course, that's the best scenario. How it plays out in practice, we will have to see.

  • I've got an idea! (Score:3, Insightful)

    by bonch ( 38532 ) on Friday August 07, 2009 @06:39PM (#28991715)

    Let's abandon decades of fast native APIs and move all our applications to a browser where they will be dependent on the fluctuating feature set of the browser wars, will require programming in JavaScript, and won't have a standard GUI framework to use so that we'll have to code our own from scratch every time as if it's MS-DOS all over again. This way, people will have a pointless, non-native middle-man between their operating systems and their apps!

    I've wanted nothing more than to program 3D in friggin' JavaScript. OUR 3D WEB GAME IS COMING FOR YOU, ID SOFTWARE.

  • by Anonymous Coward on Friday August 07, 2009 @06:55PM (#28991809)
    the limitation is you, not the language.
  • by ivoras ( 455934 ) <> on Friday August 07, 2009 @07:00PM (#28991865) Homepage
    It's "direct hardware access" in the same sense as the 2D accelerated DrawRectangle() is "direct hardware access".
  • STOP! (Score:4, Insightful)

    by markdavis ( 642305 ) on Friday August 07, 2009 @07:02PM (#28991879)

    Meanwhile I am trying to find a way to get Firefox to STOP automatic animation. It used to be easy- don't use Flash and disable animated GIF's. Now with Ajax and Javascript, it is nearly impossible.

    * Many people (myself included) can't stand movement on pages while we are trying to read things.
    * Some people are using thin clients and animation destroys network bandwidth or overloads the main server.
    * Still others are on slower, older computers and animation slows their system to a crawl.
    * And many more are on laptops/netbooks and animation pegs the CPU and quickly drains the battery.

    IMHO, a well-designed site will never create movement unless the user asks for it (with a mouse-over or click or whatever). But that would be a "in a perfect world" type fantasy.

    Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.

  • While JavaScript is not perfect, it is actually a nice little language. It's just that every retard can "program" in it, and then thinks because he wrote a for loop, he is entitled to an opinion about it.

    Few people actually know how to program properly in JS. And the only problem is that JS is too forgiving. Just as the rendering engines for (X)HTML and CSS. But that was the original point. And it's not that bad of a point either.

    Because simple scripts are way easier than people think. Every person who can play a shooter, puzzle game, or configure some stuff on his computer, can write acceptable scripts. And even total noobs can write bad ones. I think that is a nice thing.

    And this is why you can ignore the (non-pro) masses, ranting about JS.

    If it were for me, the scripting interface in browsers would have to support multiple high-level languages anyway: Python, Haskell, Java and Ruby would be those that I'd introduce. But others might want Erlang, Ocaml, and maybe even C++. Why not? If the API is clean, the interpreters work as expected, and everything is sandboxed as it should anyway...

  • by John.P.Jones ( 601028 ) on Friday August 07, 2009 @07:06PM (#28991907)

    The client can't trust the server any more than the server can trust the client. Powerful tools and healthy suspicion is needed on both ends, always has.

  • by Lord Bitman ( 95493 ) on Friday August 07, 2009 @07:11PM (#28991943) Homepage

    HTML+Javascript /is/ the standard GUI framework, that's the point.

    If you want something to be pixel-perfect, oh no, it may look a bit off.
    If you want something to be useful, HTML has been the way to go for at least a decade.
    This, like everything else ever, is not a "let's add this so people can do this" thing, but a "people are doing this, let's make it easier/more standardized by writing down what people are doing and recommending that future browsers be sure to support this"

    And of course, like everything else ever, most people aren't going to code to the low-level, but will use higher-level libraries since they care more about functionality than "control".

    As for "friggin' JavaScript"... what? When I have problems with writing javascript, it's because of IE6 or Firefox-specific bugs, what's your problem with it? Just don't want to share your source code?

  • Re:i for one ... (Score:2, Insightful)

    by Lord Bitman ( 95493 ) on Friday August 07, 2009 @07:13PM (#28991969) Homepage

    Flashblock is horribly inadequate. I'd prefer a solution that didn't involve "yes, I've wasted your bandwidth and other resources loading this flash for you- OH CRAP WAIT, IT'S FLASH! I'll tell it to go away now..."

  • Re:STOP! (Score:3, Insightful)

    by Krneki ( 1192201 ) on Friday August 07, 2009 @07:19PM (#28992019)
    On my netbook I don't have any problems with Web animations. Most of the stuff is properly blocked by Firefox plugins. Just try to configure them better, it's worth the time.
  • by rsborg ( 111459 ) on Friday August 07, 2009 @07:24PM (#28992065) Homepage

    but a language with a little rigidity, checking, and simplicity to it wouldn't hurt, would it?)

    Given the history of the web, browsers and multiple companies injecting their own funky little APIs and features, I think a strictly-typed, more "structured" language wouldn't have cut it.

    ...and you're right, a VM based solution like Java clearly didn't work back in the 90s when PCs were too slow to handle it.

  • Re:STOP! (Score:3, Insightful)

    by Hatta ( 162192 ) * on Friday August 07, 2009 @07:49PM (#28992217) Journal

    Please, don't bother replying suggesting "noscript"- it breaks necessary functionality of sites horribly.

    That's what the white list is for.

  • by sys.stdout.write ( 1551563 ) on Friday August 07, 2009 @07:53PM (#28992245)

    Absolute worst case, I have to kill the browser, but no permanent harm

    I don't think "absolute worst case" means what you think it means.

  • Re:Port 80 (Score:4, Insightful)

    by tepples ( 727027 ) <> on Friday August 07, 2009 @07:59PM (#28992285) Homepage Journal
    It does when firewalls block everything but ports 80 and 443 and software restriction policies block the installation of any software. There's just a lot less bureaucracy to deploy a web application than a desktop application nowadays.
  • by digitalunity ( 19107 ) <{digitalunity} {at} {}> on Friday August 07, 2009 @08:51PM (#28992699) Homepage

    I miss VRML.

    j/k j/k in all seriousness, the uses for 3D support in a browser is pretty limited I think. I can think of a few corner cases, such as large set data visualization, but for general use, I think it will end up being misapplied everywhere.

    I did some web programming in JavaScript years ago when browser compatibility was a serious problem and I hated it. I've heard it has gotten much better now, but I don't do web design anymore so I don't really care.

    I find myself in agreement with the GP though that there is a general trend of moving traditional desktop applications to web apps in cases where it makes little sense. Developers are working hard to come up with ways to preserve functionality and use these applications even while disconnected from a network. I think the whole thing is an exercise in futility because there will always be people like me who demand snappy, native applications that are locally stored. For security, privacy, responsiveness and other reasons, I don't see myself changing my mind on this topic any time soon.

  • by spiffmastercow ( 1001386 ) on Friday August 07, 2009 @10:21PM (#28993179)
    You know, if I were a damned good sculptor I could probably make a great statue with only a block of wood and a chainsaw... But I doubt the chainsaw would be my tool of choice. That's the problem with javascript -- we have no choice but to use it. Of course, the DOM is the real problem, but really, when have you ever used javascript for something that didn't also involve the DOM, or vice versa?

This login session: $13.76, but for you $11.88.