So we agreed WebGL would be nice if it was Java vs JavaScript, well it seems we are not the only ones thinking this:
http://www.khronos.org/message_boards/viewtopic.php?f=46&t=2353
http://www.khronos.org/message_boards/viewtopic.php?f=46&t=2351
Now if only the API was JOGL based…
or maybe both using EGL for the windowing interface.
Or maybe we could target JOGL2 ES2 API to match one of the above?
Related: http://blog.chromium.org/2010/03/introducing-angle-project.html
Basically, an implementation of OpenGL ES 2.0 written on top of DX9, written by Google (possibly the only people I’d trust to be able to pull this off well).
It even suggests that those writing ES2.0 desktop apps could still use it to get around buggy gl drivers as well, which would probably do nicely for a lot of people around here I think (myself included).
looks cool, guess with a little extra effort they can support full OpenGL. Could be cool especially for the tons of graphics cards with poor opengl drivers but decent direct3d support.
What’s worse is that I see Google have a project to wrap OGL in DX for WebGL for Windows. Which means not only is it slow 'cause it’s javascript, it’s got a OGL->DX translation layer to run through too…
I suppose it may not be as crap as the OGL->DX translation library which is out there for Windows (I forget the name) because it only has to do a subset of OGL, but still…
EDIT: Oops! I see someone else already mentioned ANGLE. WGL would be great with DIRECT access from Java. Java->JavaScript is far from ideal.
I’m not too sure about that - supporting full GL (including legacy 1.1 with fixed function pipeline) on top of the shader-only DX9 would probably mean performance would go down the drain when it has to be standards compliant and cope with the various edge cases that don’t map cleanly.
I’d rather they kept it minimal and close to the hardware. ES 2.0 fits that ideal pretty well - shader only, no fixed function but flexible and high performance. Most people don’t need the quirks and oddities of pre-ES hardware, but they use it because of compatibility reasons. Their use-cases could be just as well served with a minimal wrapper over ES 2.0.
pff… really until Internet Explorer decide to support it , it is a COMPLETLY USELESS and an UNUSABLE technologie in a proffesional project (except maybe in some geek companies that also convinced by some fanatics employees that firefox (and usng W3C) work better and is more compatible than Internet explorer : wich imediadly become fun when you just look on how many people use IE vs FF )
anyway and IMHO, this is just another stupid new idea as a lot of others that popup every month to justify the (still necessary) existence of such group and/or group part, this is not the role of browser to embed all possible plugin, this break concurency aswell as compatibility (mobile / other device / old device / different browser), really why not integrating a “Word like” canvas ? and a Video one ? and a flash one ? hey an PSP emulator one , cool no ? and finally why not a java one ? so funny to see those humble companies trying to won more markets place using exacly the same way that microsoft did and that they liked to critics in the past with an intention to appear “better” then microsoft.
vade retro satanas !!!
EDIT: to better exlain my fears, browsers are our futur Operating System : microsoft have managed in the past to “lock” it, that’s what they may try to do : “lock” the possibility for any other company to engage in the browsers market (one OS : Windows ; one search engine : Google ; and … what next ? )
EDIT2: and if anyone still think that using W3C is the way to go for compatibility … just try to validate the top world most viewed web sites … google… facebook… (both have more than 40 errors… why ? because they want to be viewed by most browser)
EDIT3 : a last note : 10 years ago, internet explorer 4 was already supporting HW access from HTML : directanimation native access from javascript/vbscript inside HTML enabling 3D inside HTML
DzzD is essentially right; WGL is next to useless. Whereas we have Java+OpenGL+applets working actually very well, today, only a bit slower than native.
Cas 
JavaScript actually isn’t as slow as you might think. Interacting with the DOM is slow - even more so if doing so causes reflows or redraws. However, if you do something with Canvas (2D/3D) you don’t have to interact with the DOM. You only have to do that once at the beginning in order to get a reference to your Canvas element and that’s it.
What’s interesting about WebGL is that it also works on mobile phones and that you can do lots of shader stuff since the baseline requirements are sorta high.
Currently it comes with a very hefty price tag though. Your target frame buffer needs to be copied over into another buffer which resides in the DOM tree. This allows the usual compositing. I.e. there can be other HTML junk in front and even below. Needless to say that this makes things ridiculously slow.
This is basically like Flash’s wmode set to “transparent”. By default wmode is “window” which means that the plugin simply renders over that target rectangle without having to copy anything over. With WebGL there is no way to change this. They intend to address this issue, but I’m not sure if they will succeed. My suggestion to add a flag for bypassing the compositing was ignored so far.
jake2/lwjgl and the start of a common es2.0 api between java and webGL?
Wow, that runs very well on Chrome. The only thing that actually limits the game is the lack of mouse capture.
For those who want to try it out, I’m hosting a build here:
http://74.207.233.86:8080/GwtQuake.html
You can reference this page for instructions on how to get a WebGL-enabled browser.
Runs at 30-50fps here if I make the window smaller. Goes down to 20 at bigger sizes. I really hope they manage to get rid of that heavy copy operation. (My graphics card obviously isn’t the bottleneck here.)
Edit: Also, I had to kill the Chrome process manually after closing the browser. It overwrote “Safe Browsing Bloom” and “Safe Browsing Bloom-journal” a zillion times a second and it didn’t stop. This didn’t happen with Chromium for example.
All this is just because Java applets take long time to start. 
It has been improved with the plugin2 and HTML5 + JavaScript is still really slower than Java + JOGL ;D
around 20-30fps on 3 year old MacBookPro with Safari, more than playable! apart from the controls
thanks for hosting!
What about Jake2? Admit it is faster.
It doesn’t matter a bit which one is faster. This is all about distribution and platforms. WebGL requires no additional plugins. As long as games are playable at an acceptable framerate, then it becomes a much more attractive option than either Java or Flash. Particularly considering that with a relatively small amount of effort you can get the same WebGL game playing across multiple platforms, including iPhone/Android. Given time for wide adoption and stable implementations, this is going to become an extremely viable option for many types of games.
There are already some game engines being developed on top of WebGL, such as Copperlicht. Anyone with a capable browser installed who wants to play around with it and see what it can do, that’s a good place to start.
Of course it’s faster. WebGL without compositing would be about 3-4 times faster. Anything which uses h/w acceleration (for 3d, that is) and without that heavy copy operation is going to be a lot faster.
The lwjgl applet ran more than 5 times faster for example. And that was with my old onboard GPU. I did hit the fill rate limit there.
[quote=“aldacron,post:17,topic:34744”]
I disagree with you because the difference of frame rate is important and lots of people have laptops with crappy integrated graphics chips which is already a big limitation. If you add another limitation by choosing WebGL, you increase the probability that lots of players won’t be able to play with your games comfortably.
It is more difficult to get an acceptable frame rate with WebGL than with JOGL but if you succeed, the users will find WebGL more attractive because there is no security popup.
Apple will never authorize anyone to deal games without using the AppStore.
[quote]WebGL requires no additional plugins.
[/quote]
you are right, it does not requiere a plugin as : virtools / java+opengl / unity / wrml / shocwave / O3D / 3DVIA / turntool / and many many more … but … for now it requiere something a lot more complexe to setup… it requiere a full software installation (understand => a capable browser).