Stories
Slash Boxes
Comments
typodupeerror delete not in
  • Preferences

Comments: 239 +-   WebGL Standard To Bring 3D Acceleration To Browsers? on Friday August 07 2009, @05:11PM

Posted by ScuttleMonkey on Friday August 07 2009, @05:11PM
from the need-faster-delivery-of-js-already dept.
graphics
software
entertainment
games
technology
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."
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

WebGL Standard To Bring 3D Acceleration To Browsers? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • i for one ... (Score:5, Funny)

    by neonprimetime (528653) on Friday August 07 2009, @05:17PM (#28991543)
    >>> Does WebGL sound like your dreams come true, or are you frightened by the thought that all those hideous Flash-only marketing pages will now have access to 3D acceleration?

    ... am frightened

    • Re: (Score:2, Funny)

      by ojintoad (1310811)
      I already have enough trouble shooting the monkey in 2d. I'll never win that free IPod now.

      • Re: (Score:3, Informative)

        by fuzzyfuzzyfungus (1223518)
        Since the GL wouldn't be a plugin; but rather javascript accessible, you'd probably want something along the lines of a greasemonkey script that stripped all references to webGL from site scripts before execution. Not total rocket surgery; but could be tricky if you want webGL features and want to avoid the webGL ads. On the plus side, adblock-style URL based blocking would still work, since(unlike flash blobs) the webGL stuff would just be part of the HTML/javascript/CSS of the page...

        • Re: (Score:2, Insightful)

          by Lord Bitman (95493)

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

  • ... who the Khronos Group is, exactly? The linked article refers to them as 'a consortium', but I've never heard of them.

    Basically I'm wondering if this is any different than my friend Jim announcing a web standard.

    • Re:Could someone explain... (Score:5, Informative)

      by e4g4 (533831) on Friday August 07 2009, @05:27PM (#28991629)
      read about them...here [wikipedia.org] They appear to be the people who run the OpenGL standard; Apple, Intel, and several others are members.
    • The Khronos Group is the body behind the (current) further development and standardization of OpenGL. In terms of getting this adopted on the web, the support of the browser guys is what counts; but Khronos is the standards group of note behind OpenGL.

      • Thanks to all for the replies and Google proxy searches. I guess I should have been more direct, though, and simply said:

        Shouldn't Slashdot submitters or editors provide an explanatory link when referencing a group/individual when it's probable a large number of readers won't have a priori knowledge of the group/individual? Alternatively, if I'm going to have to do some background research anyway - then a submission like this could be distilled down to the single sentence "The Khronos Group did something in

        • Re: (Score:3, Informative)

          by beelsebob (529313)

          Simple answer, yes, the editors should do that. But, in this case, no such thing has happened. The Khronos group is an organisation that slashdotters almost all know as well as the ISO or IEEE.

  • Javascript and direct hardware access. (Score:5, Funny)

    by Tackhead (54550) on Friday August 07 2009, @05:24PM (#28991603)
    What could possibly go wrong?

    What's next, a way to make web browsers faster by making /dev/kmem remotely writable?

    • Re:Javascript and direct hardware access. (Score:4, Interesting)

      by BuR4N (512430) on Friday August 07 2009, @05:39PM (#28991711) Homepage Journal
      "What could possibly go wrong?"

      WebGL is based on OpenGL ES and together with javascript bindings its a really neat way of expand the usage of a browser without the need for a multitude of different plugins (each coming with their problems and security issues). Standards is good for you, and to make certain applications we will need 3D directly in the browser (I'm not just thinking geek stuff here, lots of stuff like you need a standalone program for today could run directly in the browser, planing your home, drag around those furnitures and when your happy, just click order !).

    • This isn't such a bad idea, to be honest. OpenGL shaders can be made using almost any language in existence, including(but not limited to) C/C++, Java, Python, Ruby, etc. etc.

      I can see more problems with letting a website block keyboard presses and mouse buttons, and that doesn't seem to be hugely abused in Firefox.

      I do hope there's some sort of filtering for malicious content. Up until now OpenGL has been run from "trusted" programs that already have full access to your computer. I remember a while back wh

    • Re:Javascript and direct hardware access. (Score:5, Insightful)

      by ivoras (455934) <(ivoras) (at) (fer.hr)> on Friday August 07 2009, @06:00PM (#28991865) Homepage
      It's "direct hardware access" in the same sense as the 2D accelerated DrawRectangle() is "direct hardware access".

  • Port 80 (Score:2, Insightful)

    by Anonymous Coward

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

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

      by tepples (727027) <<moc.thgienip> <ta> <6002hsals>> on Friday August 07 2009, @06: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.

    • Re: (Score:3, Funny)

      by TheRaven64 (641858)
      Just wait. Next week we're going to announce a binding of the X11 protocol to XML over HTTP. Then you can have rich applications displayed remotely in your browser, using a JavaScript X server using the canvas tag. There is a small amount of overhead created by having every binary X11 message encoded in XML, but we think it's worth it because it runs in your browser.

  • For the love of god replace javascript (Score:3, Interesting)

    by presidenteloco (659168) on Friday August 07 2009, @05:29PM (#28991639)

    Is anyone at all working on something that is not as loosy-goosy and hokey as javascript for client-side computing?

    I've used Adobe ActionScript (stricter variant of JavaScript) and it is getting a little better, but why do we think "oh, it's the client-side. Let's go back to (essentially) Basic for programming."

    (Still moping I didn't get my Applets.)
    (Ok, Java is a bit too ugly (accessor hell)
    but a language with a little rigidity, checking, and simplicity to it wouldn't hurt, would it?)

    • Re: (Score:3, Insightful)

      by Anonymous Coward
      the limitation is you, not the language.

      • Re: (Score:3, Insightful)

        by spiffmastercow (1001386)
        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?

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

      • Re: (Score:3, Interesting)

        by MemoryDragon (544441)

        Dont get me wrong I do most of my work with javascript, and I know the inner depths of the language. And as far as I can see the language itself is as powerful as every other dynamic language like ruby or groovy for instance. But the designers missed a few things, which then have to be simulated and sometimes due to having a simulation of those language constructs can cause cross implementation collisions. Those would be easy to fix, introduce real classes and inheritance or simply make a standard on how to

    • Re: (Score:3, Insightful)

      by rsborg (111459)

      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.

      • Sorry. What can't you trust on the client, specifically?

        Also, what you are saying is going against the trend, which is to richer functionality on the client for better interactivity, while getting data and
        some heavy-duty processing and identities etc from the server.

      • Re: (Score:3, Insightful)

        by John.P.Jones (601028)

        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.

  • Fast enough for web browsing??! (Score:5, Insightful)

    by formfeed (703859) on Friday August 07 2009, @05: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, @05: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.

  • VRML (Score:3, Interesting)

    by timeOday (582209) on Friday August 07 2009, @05:42PM (#28991725)
    Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

    • Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

      What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...

      If I'd had tools like (today's) Blender back then, and the hardware to back it up, I might have done something with VRML...

      • Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.

        What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...

        I feel compelled to add, this was a point in time at which streaming audio over the internet was still a big deal.

      • Re: (Score:3, Interesting)

        by Joce640k (829181)

        VRML is alive and well ... and living in a group called "Kronos". It's every bit as awesome as it ever was.

  • So the web browser, in the end, will just be one big common runtime environment? That's one way to get compatibility across OSes I guess. If proprietary plugins were to be written to run entirely in a W3C compatible environment, then we'd be better off.

    But it still seems like there will always be some sort of proprietary extension that one group will try and control. Businesses will want to set up tollbooths just for the sake of a "guaranteed revenue stream". What this really means is a tax that doesn'

  • STOP! (Score:4, Insightful)

    by markdavis (642305) on Friday August 07 2009, @06: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.

  • several sources...are mistaken... (Score:5, Informative)

    by daithesong (1124065) on Friday August 07 2009, @07:37PM (#28992597)
    "Several sources are reporting that while native audio/video support has been dropped from the HTML 5 spec" is hard to reconcile with http://www.whatwg.org/specs/web-apps/current-work/#video [whatwg.org] (and the same document is available at the W3C, O doubters). It seems (gasp) that several sources can be...wrong!

    • Re: (Score:3, Informative)

      by shutdown -p now (807394)

      I think that aforementioned several sources are confusing dropping Vorbis/Theora as a required codec with dropping audio/video elements from HTML5 altogether. Ironically, if you actually open TFA (don't worry, no need to read it) and click on the link that's formed by the words "dropped from the HTML5 spec", the article which opens is indeed about dropping Vorbis/Theora, and it's on the same website. Looks like they don't read their own articles - just like /.

  • Video/audio did NOT get dropped (Score:4, Informative)

    by Lennie (16154) on Saturday August 08 2009, @08:54AM (#28995633) Homepage

    Their just isn't a recommendation about what codecs should be supported in the spec.

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

      by bonch (38532)

      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'

      • Re:I've got an idea! (Score:5, Interesting)

        by SanityInAnarchy (655584) <ninja@slaphack.com> on Friday August 07 2009, @06:07PM (#28991919) Journal

        will require programming in JavaScript

        Why is this a bad thing? Or what would you suggest as a better language?

        Most people who hate Javascript don't really understand it. I qualify that as "most" because a few people do know enough about it to actually have good reasons for hating it.

        won't have a standard GUI framework to use

        HTML is more standard than about any other GUI framework, even if less featured.

        In fact, something to notice -- most people seem determined to style away the standard GUI elements. Below this message, you'll almost certainly see a "Reply to This" button and a "Parent" button, and unless you've disabled your CSS, they probably look nothing like your standard native buttons.

        The issue is that most web designers hate these things, and think they're "ugly". Whether actual users care is up for debate -- they don't seem to have a problem with Google's homepage, for example.

        we'll have to code our own from scratch every time as if it's MS-DOS all over again

        You mean the MS-DOS, where the network was nearly nonexistent, and applications would largely be written in C or assembly?

        I understand your sentiment that the browser feels like a step back, but hyperbole doesn't help your argument.

        This way, people will have a pointless, non-native middle-man between their operating systems and their apps!

        Better this than Java or C#.

        What's more, it's hardly pointless. Or would you rather go back to the days when if you wanted something cool, like the ability to check the weather, receive email, or watch TV, you'd have to download an untrusted (possibly virus/spyware infested) binary .exe, run it on Windows, and hope it doesn't have some weird incompatibility with everything else on your system?

        I much prefer the ability to try out pretty much anything I want, in my browser, without having to download/install anything, or uninstall it later. Worst case, I reload the page, or close the tab. Absolute worst case, I have to kill the browser, but no permanent harm.

        Oh, and they're portable. I can play with the same apps on Windows, Linux, OS X, an iPhone...

        You could argue that the browser isn't the best possible way we could've accomplished that, but those are real advantages it has over the vast majority of desktop apps, especially "fast" ones.

        I've wanted nothing more than to program 3D in friggin' JavaScript.

        Better than programming 3D in friggin' Flash.

        If people are going to insist on taking the Web in this direction, wouldn't you rather it be based on cross-platform open standards?

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          The very name "JavaScript" confuses uninformed people who assume "Java" and "JavaScript" are the same thing. Despite posting as Anon, I can say I've never had much problem with JavaScript as a standard. (I know, I know. The name is really ECMAscript these days, but who calls it that?)

          The other side of using JavaScript is that it was slow -- so the 'interpreted versus native' argument would come back up, like it did back in the days of Visual Basic versus Visual C++. But with the advances made in the last...

        • Re: (Score:3, Insightful)

          by sys.stdout.write (1551563)

          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:I've got an idea! (Score:4, Insightful)

          by digitalunity (19107) <digitalunity@@@yahoo...com> on Friday August 07 2009, @07: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.

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

        by Lord Bitman (95493) on Friday August 07 2009, @06: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: (Score:3, Interesting)

        by cromar (1103585)
        What needs to happen is that the OS needs to become more browser-like not vice versa (bare with me here). Modularity and separating the parts of the OS into distinct UI, data, and code structures offers amazing customization and extension (CSS jQuery), and is something browsers do right. How does that apply to the OS, you say? Imagine a modular OS encompassed basically by 1) a semi-p2p database file structure (like the web basically, but not HTML - something closer to XML), 2) modular code er "pieces" -
    • Getting everyone used to not downloading stuff is step 1
      Step 2 is making it impossible for anyone to download anything
      And step 3 is pay-per-use of the glorious cloud and all of it's constant revenue stream goodness.

    • Re: (Score:3, Funny)

      by Achoi77 (669484)
      Yeah... it would be real nice if the general public had access to the source code in some kind of Open fashion regards to browsers such as Firefox or Webkit/Safari/Chrome so that stuff like exploits can be patched, making it would be possible to have tons of eyeballs pore over the code and be able to submit fixes on behalf of the community, or point out bad stuff that perhaps some other developers may have missed.

      That would be cool.
Search
Because I don't need to worry about finances I can ignore Microsoft and take over the (computing) world from the grassroots. -- Linus Torvalds

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.