Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
GUI Graphics The Internet Games Technology

Initial WebGL Support Lands In WebKit 181

appleprophet writes "WebGL is an upcoming standard from the Khronos Group, the same standards body behind OpenCL and OpenGL ES. It defines the use of OpenGL in websites using the standard canvas element. In other words, websites will be able to render hardware accelerated, 3D graphics natively inside of a web page. In the last week, WebKit, the rendering engine behind Safari and Google Chrome, has added initial support for WebGL, which means it probably won't be too long before Macs and iPhones everywhere get OpenGL web apps. This could have big implications for gaming. HTML5 has steadily been encroaching on desktop applications' territory, but I don't think many people expected browser-based, hardware-accelerated graphics this soon."
This discussion has been archived. No new comments can be posted.

Initial WebGL Support Lands In WebKit

Comments Filter:
  • by erko ( 806441 ) on Sunday September 13, 2009 @04:08PM (#29407193)
    Quake live (and similar apps) require you to download a plugin.

    Ideally, webGL will eventually be included in browsers so any webpage could use accelerated GL without requiring you to download a plugin first. (I'm not an expert, this is just what I've gathered so far, corrections are welcome).
  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday September 13, 2009 @04:10PM (#29407207) Journal

    Quake Live requires you to download a plugin -- and it's a specific plugin, for a specific game (Quake Live).

    WebGL, or O3D -- maybe they're the same thing? Anyway, both are planned to be either a plugin, or actually included in the browser. And they're just a 3D API -- it means that once you have this plugin, any game will work.

    So, kind of like Flash is for crappy 2D games, only actually an open standard, and with decent cross-platform support.

    My question was, WebGL and O3D seem to have identical goals. Is there a difference?

  • by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Sunday September 13, 2009 @04:15PM (#29407233) Journal

    Here's a nice summary [google.com].

    It seems O3D is higher-level, thus allowing more to be handled by the browser, whereas WebGL forces Javascript to handle just about everything.

    I'm not sure which one I like better. In theory, I like Javascript handling everything. In practice, I don't know enough about VMs to say whether Javascript could be made to perform well enough.

  • by beelsebob ( 529313 ) on Sunday September 13, 2009 @04:56PM (#29407519)

    Just one phone? Web Kit is used on almost all Nokia phones, android phones, and iPhones, and probably a bunch more after that.

  • by Animats ( 122034 ) on Sunday September 13, 2009 @05:02PM (#29407565) Homepage

    This is about Try #4 for 3D on the Web. Web3D [web3d.org] was an XML representation of VRML. Unfortunately, the effect of the Web3D consortium was to kill VRML in favor of a vaporware concept.

    3D in the browser is done well in Macromedia Shockwave. Try this 3D driving game. [swgamers.com] The Shockwave player is supposedly available on 58% of PCs. [adobe.com] Some versions of Shockwave even had the Havok physics engine, but Macromedia stopped paying Havok for the license and took that out.

    The main problem with Shockwave is that it doesn't start as fast as Flash does. Flash has a nice scheme for interleaving the timeline and the asset data, so that playing starts very quickly. At least if the content is authored properly. Also, Shockwave authoring tools are expensive.

    About Java 3D, the less said, the better.

    The problem with offering OpenGL access to Javascript is that Javascript isn't a good language for fast matrix math. Also, authoring tools will have to be developed. You can't effectively author 3D content in a text editor.

  • by appleprophet ( 233330 ) on Sunday September 13, 2009 @05:17PM (#29407665) Homepage

    While Assembly demo coders might enjoy the challenge of working in such a limited environment, the rest of the world should wait for some real improvements.

    Most of your complaints have been addressed in other modules of HTML5. See the media module for native sound support and web workers for threading support.

    Regarding debuggers, there are a few excellent debuggers for JavaScript capable of profiling and doing all sorts of stuff. The most notable being WebKit's native Web Inspector and the FireBug extension.

    Performance concerns with "fill color" and such are not an issue because they are offloaded to the graphics card.

    Full screen mode is controlled by the user agent, not the web page for obvious reasons. Most browsers have support for a full screen mode in some fashion.

    Now this is not to say that it's perfect. However, things are looking pretty good. :) This is definitely the future, the question is just how long will it take to get there.

  • by hkmwbz ( 531650 ) on Sunday September 13, 2009 @05:26PM (#29407739) Journal

    How about the browser with the biggest share of the mobile phone market

    You mean Opera [statcounter.com]?

  • by derGoldstein ( 1494129 ) on Sunday September 13, 2009 @05:41PM (#29407817) Homepage

    A common comparison that has been made is that WebGL would be used like Canvas whereas O3D would be more like SVG. (WebGL will be *part* of canvas, of course, but I mean in terms of uses and applications)

    If you want links to many discussions about the approaches and comparisons, check out this page [ajaxian.com].

    Since canvas is already known territory (comparatively), and JavaScript is being optimized like crazy by all browser developers, I'd bet that you should expect to see WebGL picked up much faster than O3D. Developers that are already comfortable using canvas for some 2D representations will have only a small step to take to reach WebGL.

  • by loufoque ( 1400831 ) on Sunday September 13, 2009 @06:04PM (#29407973)

    Javascript is so limited that I fail to see how it will be to make this actually usable and applicable in useful situations

    Javascript is not particularly limited. It is turing-complete, of course, and provides a nice type system: dynamic duck typing on top of a prototype object oriented type design. It has garbage collections, closures, reflection...
    Probably more expressive and flexible than your average programming language.

    Maybe what you mean is that it is lacking a bigger standard library.
    Well, as it is, it is certainly much bigger than the standard C one.

  • by mdwh2 ( 535323 ) on Sunday September 13, 2009 @07:48PM (#29408713) Journal

    Javascript isn't a good language for fast matrix math.

    The matrix calculations required for rendering are done by OpenGL, not the caller programming language (the advantage of doing this way is that it can be hardware accelerated).

    Also, authoring tools will have to be developed. You can't effectively author 3D content in a text editor.

    I'm unclear what sort of tools you refer to? Presumably people would use the same 3D modelling software they'd use for any other OpenGL application.

    OpenGL has the advantage over the other things you list in that it's (a) an existing widely used API, and (b) it has hardware acceleration support.

  • by ardor ( 673957 ) on Sunday September 13, 2009 @11:23PM (#29409969)

    The matrix calculations required for rendering are done by OpenGL, not the caller programming language (the advantage of doing this way is that it can be hardware accelerated).

    No they are not. The vertex transformations are hardware accelerated. The matrices itself are done either by the application of by the driver (when calling something like glTranslate). Matrix manipulations never ever are done by the graphics hardware.

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...