jogamp › jogl

WebGL specification 1.0 is final — and also, WebCL?

Classic

List

Threaded

12 messages Options

BrickFarmer

WebGL specification 1.0 is final — and also, WebCL?

This should interest a few people here:

http://learningwebgl.com/blog/?p=3396
original:
http://www.khronos.org/news/press/releases/khronos-releases-final-webgl-1.0-specification

So when are we going to add a WebGL binding to JOGL? :)

It sounds like there are already quite a few 'post PC' devices supporting this.

What next, JOGL on 1 million iPhones anyone?

Experiments: https://github.com/WhiteHexagon

Michael Bien

Re: WebGL specification 1.0 is final — and also, WebCL?

JOGL supports OpenGL ES already. A Java-WebGL binding would be redundant. I would also like to note that web is only one possible deployment scenario for an java application.

iPhone is an legal issue for java in general.

best regards,

michael

On 03/04/2011 08:40 AM, BrickFarmer [via jogamp] wrote:

This should interest a few people here:

http://learningwebgl.com/blog/?p=3396
original:
http://www.khronos.org/news/press/releases/khronos-releases-final-webgl-1.0-specification

So when are we going to add a WebGL binding to JOGL? :)

It sounds like there are already quite a few 'post PC' devices supporting this.

What next, JOGL on 1 million iPhones anyone?

If you reply to this email, your message will be added to the discussion below:
http://forum.jogamp.org/WebGL-specification-1-0-is-final-and-also-WebCL-tp2631673p2631673.html

To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

-- 
- - - -
http://michael-bien.com

gouessej

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

In reply to this post by BrickFarmer

Hi!

This is not the way to go as WebGL won't be supported by Microsoft Internet Explorer and JavaScript is not as fast as Java which means that applications ported from Java + JOGL to HTML5 + JavaScript + WebGL would be noticeably slower. Maybe some efforts could be done to allow the use of WebGL in GWT but in my humble opinion, it is not the matter of JOGL. JOGL has only a few contributors; if you really want to use JOGL with WebGL, feel free to contribute. On my view, we should not waste any time with platforms and devices that are not open enough, that is why I don't try to use Java on iphones and consoles.

I'm only a "small" contributor, I consider that the priorities consist in having a stable version of JOGL 2 providing at least the same services than JOGL 1.1.1a and providing a full and reliable implementation of new features that have already been announced (especially NEWT). Maybe the extension of NEWT for SWT could be "experimental" in JOGL 2.0 and become more reliable and complete in JOGL 2.1. Android support would be easier to implement than WebGL support and maybe more useful as Android supports Java.

Java 1.7 will provide an AWT-less or AWT-free plugin for applets which will have a very short startup time (less than one second). Therefore, focusing on pure Java solutions in the browser is a good option instead of using WebGL that is still not implemented in Microsoft Internet Explorer. I rarely use NEWT, I don't know if it is possible to use it in applets without any AWT or Swing component.

As Michael said, web is only a possible scenario of deployment.

Julien Gouesse | Personal blog | Website

Sven Gothel

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

In reply to this post by BrickFarmer

On Friday, March 04, 2011 08:40:24 BrickFarmer [via jogamp] wrote:
>
> This should interest a few people here:
>
> http://learningwebgl.com/blog/?p=3396
> original:
> http://www.khronos.org/news/press/releases/khronos-releases-final-webgl-1.0-specification
>
> So when are we going to add a WebGL binding to JOGL? :)

Well, I thought about this too, ie allowing a more tight HTML5 integration
using WebGL's offscreen (layer) rendering for later compositioning.

The problem right now is to gain access to WebGL's current context.

For example:

+++
<!DOCTYPE html>
<html>
<head>
<title>WebGL + JOGL</title>
<script>
var gl;
var joglApplet;

function webGLStart()
{
var canvas = document.getElementById("canvas");
try { gl = canvas.getContext("experimental-webgl");
} catch(e) {}
if ( !gl ) {alert("Your browser does not support WebGL"); return;}
gl.viewport(0, 0, width, height);
joglApplet = document.getElementById("GearsExtApplet");
joglApplet.display("init");
...
</head>
<body id="body" onload="webGLStart();" onresize="reshape();">
<canvas id="canvas" width="800px" height="600px">
There is supposed to be an example drawing here, but it's not important.
</canvas>
<applet id="GearsExtApplet" name="GearsExtApplet" code="org.jdesktop.applet.util.JNLPAppletLauncher"
...
+++

would integrate the JOGL Applet with WebGL.

But WebGL runs in the browser process (or it's own if they have a proper and secure layering)
and the Java Applet runs in it's own process.
This renders it impossible to fetch WebGL's current GL context from the JOGL side.

Until we have access to the native WebGL context or drawable, I am afraid we are out of luck.

>
> It sounds like there are already quite a few 'post PC' devices supporting
> this.
>
> What next, JOGL on 1 million iPhones anyone?

Sure .. but natively via dalvik etc :)
It's in the pipe ..

~Sven

Sven Gothel

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

In reply to this post by BrickFarmer

BrickFarmer

Re: WebGL specification 1.0 is final — and also, WebCL?

In reply to this post by BrickFarmer

I think the performance is becoming less of an issue. Javascript is probably running as fast now as Java was when JOGL first got going, especially since ES2 means most of the work is on the GPU these days. The browser compositing is probably the biggest drain on performance for WebGL.

I really like the sound of 1 second applet startup! Although I will only belive it when I see Oracle deliver this for windows and especially OSX.

I doubt we could ever grab the WebGL context from within an applet, since WebGL is inside the secure sandbox and plugin-free, whereas Java is on the plugin side. Although that is the whole advantage of WebGL :)

What I'm thinking though is just something that takes our JOGL code and generates the equivalent Javascript. Would that appeal to anyone? I'm not volunteering at this point :) but it might be something I have some time for in the summer...

I just love the idea of still writing in Java, but being able to deploy to iOS, Android, and all the current desktops. And I'm really not bothered about IE support. Mobile devices seem to be the winner in games these days anyway.

+1 vote for JOGL2 release asap and 2.1 for new goodies

Experiments: https://github.com/WhiteHexagon

Sven Gothel

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

On Friday, March 04, 2011 19:03:57 BrickFarmer [via jogamp] wrote:
>
> I think the performance is becoming less of an issue. Javascript is probably
> running as fast now as Java was when JOGL first got going,
Agreed .. even thought javascript is still around 2-3 times slower in some cases
http://shootout.alioth.debian.org/u64/javascript.php
it's only about time IMHO when they 'line up'.

> especially since
> ES2 means most of the work is on the GPU these days.
I don't think this is related. You still might have cpu based preprocessing,
data transfer/management, etc.
Don't know how well javascrip's API allows DMA transfers using an equivalent
of nio let's say etc. I am afraid these things just don't exist.

Much more important here IMHO is maturity and convenience,
but since I have very very little experience in 'hacking' together web pages
with javascript - I really can make an objective statement here anyways :)
Maybe it's more about the less complex use-cases, even though you sure can
send complex javascript source through the http/gzip-ped channel :)

So IDEs .. existing tools etc may change the landscape.
Indeed .. too bad that almost nodbody offered a nice UI tool for the
Java/JOGL combination :)

> The browser
> compositing is probably the biggest drain on performance for WebGL.
YES, since it is a constraint.
For JOGL we actually desire offscreen rendering into a browsers HTML5 DIV layer
for later composition - as an option of course.
If anybody has an idea it would be greatly appreciated.
For example .. how to target the browsers 'offscreen' pixmap/bitmap memory (whatever)
with JOGL .. and sync rendering ?

>
> I really like the sound of 1 second applet startup! Although I will only
> belive it when I see Oracle deliver this for windows and especially OSX.
Well, I can tell you I have seen my experiments with an AWT less plugin3
doing exactly like this .. below one second incl. launching JOGL!
Technically it is very much possible - it just would need the will
and 'political strength' to execute.

>
> I doubt we could ever grab the WebGL context from within an applet,
As described above, a native offscreen windowing id would be the true desired feature,
since we really don't need WebGL at all. It was just a thought ..

> since WebGL is inside the secure sandbox
Well .. that really depends on the implementation.
Last time I checked .. it was running within the browser process,
hence it is everything but secure.
Maybe it has changed now ? Dunno.

> and plugin-free,
That depends on the definition of a plugin.
For example you could deploy FF3 + JRE6, which cache is populated with JOGL :)

> whereas Java is on the plugin side.
And IMHO a good thing - proper seperation of roles and features.
The only downside (practical) is/was the very very poor Applet support within browsers
until today (since AWT initialization still takes forever > 0.5s).

> Although that is the whole advantage of WebGL :)
One monolithic beast .. well :)

In the end, I guess the user doesn't really care.
However the browser vendor do a bit, since they have to implement it for their product.
Mozilla and other 'open source' kit's may share - sure.

It should just work.
Which brings you back to Java vs ECMA Script, read above.

>
> What I'm thinking though is just something that takes our JOGL code and
> generates the equivalent Javascript. Would that appeal to anyone? I'm not
> volunteering at this point :) but it might be something I have some time
> for in the summer...

I don't even know why one should do that ?
Maybe some 'tools' or utilities.
However, JOGL is quite low level with some amnenities .. but thats it.
Utils maybe be ported if anybody has an interest .. sure.

>
> I just love the idea of still writing in Java, but being able to deploy to
> iOS, Android, and all the current desktops. And I'm really not bothered
> about IE support. Mobile devices seem to be the winner in games these days
> anyway.

Yeah that would be .. seeing Steve Jobs allowing ECMA Script, WebGL and all of that
defeating his whole VM bullshit politics to bind his customers to his Apple API
and hence it's AppStore :)

however .. (again) we will deliver JOGL on android.

>
> +1 vote for JOGL2 release asap
Dude .. it is released (again) v2.0-rc2
Let's not split hairs about the term 'release' and 'version numbers'.

> and 2.1 for new goodies
v2.0-rc3 first :)

then sometime:
v2.0
v2.0.1 (add ons, fixes, compatible)
...

v2.1 (with some API changes - maybe !)

~Sven

BrickFarmer

Re: WebGL specification 1.0 is final — and also, WebCL?

>> +1 vote for JOGL2 release asap
>Dude .. it is released (again) v2.0-rc2
>Let's not split hairs about the term 'release' and 'version numbers'.
>
>> and 2.1 for new goodies
>v2.0-rc3 first :)
>then sometime:
>v2.0
>v2.0.1 (add ons, fixes, compatible)

This is what I don't yet understand. As an outsider approaching JOGL2 the first thing they see is 'release candidate' which totally undervalues this 18months hard effort you guys have dedicated to JOGL2. We need a final V2.0 asap. Now I see Java 1.5 and Android being added and thus more delay to the V2.0. Seriously what's the eta for V2.0?

coming back to WebGL, I think you are probably right. It just makes me nervous for JOGL2 future when I see so much energy being spent on WebGL, only MS is missing but they can soon catchup now things are final. Are you still in touch with Ken, I guess he would know about access to browser rendering surfaces and the compositing stuff in browsers.

>I don't even know why one should do that ?
Regarding the 'JOGL2 to Javascript' idea. My thought is reaching more clients from a common code base. As having a smooth browser experience.

Actually let me explain what I'm trying to do with JOGL2. I'm still part-time working on my game, hopefully starting in May I'll have 2 months full-time trying to complete it (hence some time to help with JOGL). What I've found from users is a general distaste for webstart & applets. pluggin3 might solve that (depending on how many 'warning popups', certificates, etc are involved and eta?). Otherwise I need to make the experience as smooth as possible. Java will never be on the right side of the security fence in the browser, so I'm left wondering about Javascript & WebGL. Now I still want to develop in Java, so a translation down to Javascript seems to make most sense here. That way I get the best of both worlds. JOGL2 on desktops and WebGL for the rest of the world including Android, Apple, Nokia, etc.

I know we have been around this discussion a few times in the past, but I really need guidance here. Would people here currently use JOGL2 with NEWT for a production ready game?

Here is an idea, lets collectively work on an open-source minecraft clone that clearly demonstrates the superior features and performance of JOGL2. This will allow us to investigate all the deployment issues involved in such a project, and also give JOGL some high visibility. It would also act as a good template for wannabe game developers like myself :)

Experiments: https://github.com/WhiteHexagon

gouessej

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

In reply to this post by BrickFarmer

Hi!

BrickFarmer wrote

I think the performance is becoming less of an issue. Javascript is probably running as fast now as Java was when JOGL first got going

I completely disagree with you. On one hand, I studied the implementation of computing language during my Master's degree and JavaScript typing has some consequences on the way it is executed, it will never be as fast as Java even though JavaScript performances will go on being improved because much more things have to be controlled at runtime with loosely typed languages. Kenneth Bradley Russell has been working on an equivalent of NIO buffer for JavaScript and WebGL, it is a good stuff :)

On the other hand, the performance is still an issue especially on mobile phones. We should not do everything on the GPU, it is an inefficient approach, splitting the jobs between the CPU and the GPU is more efficient. Therefore, the speed of the CPU has an important impact on the performance. Some tasks are particularly resource hungry, time consuming, for example the physics, especially the collision system and the space partitioning. If you use a language that is between 2 and 20 times slower than Java on the CPU on mobile phones, low end smartphones with Android and even high end smartphones with Android will suffer. First Person Shooters are not numerous on Android, such a penalty in the performance would drive them unplayable.

As a consequence, keep in mind that WebGL has its own advantages but it is not a magic tool. It will have some (a lot of?) success even though it is less mature than Java and it has less API and tools but it is not the most suitable solution especially in performance critical applications, especially in scientific visualization and non trivial 3D games with large environments.

Julien Gouesse | Personal blog | Website

BrickFarmer

Re: WebGL specification 1.0 is final — and also, WebCL?

>>it will never be as fast as Java even though JavaScript performances will go on being improved
Agreed. But how many years did we have to listen to people telling us Java was too slow for games :)

And how much performance do you need? Sure physics is computationally intensive, but with the mobile platforms currently switching to dual core (tegra 2, A5, etc) and the focus on browser speed, (which means javascript performance), it can't be long before this is a viable option.

But your arguments are good, and they help and reassure me that although WebGL could one day be the answer, it's not today :) Currently the only way to get decent performance is via JOGL or relevant platform native code.

But what a shame Java isn't getting the focus javascript is, and probably never will with Oracle sitting on it. Sounds like even Java on Android is under threat now, let alone it ever being embedded again in any browser.

Experiments: https://github.com/WhiteHexagon

BrickFarmer

Re: WebGL specification 1.0 is final — and also, WebCL?

This is smoother than lwjgl version on my mac :) albeit without the new lighting model minecraft now has. and it's only a single map block., but still...

http://mrdoob.github.com/three.js/examples/webgl_geometry_minecraft.html

Experiments: https://github.com/WhiteHexagon

gouessej

Re: WebGL specification 1.0 is final — and also, WebCL?

Administrator

This post was updated on .

In reply to this post by BrickFarmer

The situation with Java was really different as Java has been used in video games since 1995 despite the silly trolls about its slowness. Java is able to run 3D games faster than C/C++ since 2004. Java and C/C++ are both strongly typed languages whereas JavaScript isn't such a language. As some researchers in IBM said, Java is able to be faster than C/C++ because it is precompiled and interpreted, it benefits of optimizations that are not possible in purely compiled languages. JavaScript is slower than Java even with Rhino... Therefore, comparing current JavaScript situation to Java in the nineties is absurd in my humble opinion. JavaScript drives the interpretation more complicated, I don't see any chance of getting better performance than Java in this case, really.

I have nothing against scripting languages but I don't encourage people to write softwares only with them. It is better to use them where they give some interesting possibilities, for example to ease the customizations of existing applications at runtime, for AI, etc... Scripting languages are more accessible for people who are not true full-time programmers.

I don't target only very expensive smartphones with very high end GPUs and dual core CPUs. The HTC Dream G1 is slower than my Celeron 700 Mhz. I want to support such machines, I would like to get a steady frame rate with a single core and 250 Mhz as a minimal clock frequency. Machines become faster as time goes by, it does not mean that we have to waste some CPU time in using solutions that lack optimizations. If Java was really slow, I would not use it. Quake 2 can work fine on a Nintendo 64 with 4 MB of RAM and 100 Mhz. I think that doing the same in Java is possible in term of speed, Jake 2 port to JavaScript is about 3 times slower, that is not what I'm looking for.

WebGL will be an answer for lots of projects in 2D and 3D as it is seducing, it requires no plugin, it is fast enough for a lot of applications (not all). It depends on what you really want to do. Honestly, I'm an outsider, only a very few people still want to support very low end machines with only OpenGL 1.2, my opinion is not representative. Lots of programmers prefer telling you that your hardware is not good enough instead of admitting that their tools are not fast enough. If WebGL fits better in your needs than JOGL, use it but I have to warn you about the limitations of these technologies.

I don't like Oracle but the plugin 3 is strangely the only excellent sign of interest for the client side that it has given since it controls Sun Microsystems. In my humble opinion, the bad reputation of Java has been caused by Microsoft with its crappy very slow VM and Java on Android is becoming more interesting with the JIT compiler (it still lacks on optimizations in comparison with J2SE For Embedded).

Lol, I have seen projects whose LWJGL renderer is twice slower than its JOGL equivalent

Julien Gouesse | Personal blog | Website