Catch 22 for jogl

[Riven]

I can't quite see the point of coding it in Java and then attempting to translate it...? Just, y'know, learn Javascript, and get on with it...?

Cas

- Typesafe
- Maintainability
- Superb IDE support
- Realtime compilation
- Refactoring
- Debugging
- etc. etc.

When I work with Javascript (and yes, I do write a lot of Javascript) my hands feel tight and it feels like coding Java in notepad again. Horror. Better to have some code converter!

I think the easiest option would be a Java interpreter in Javascript. I know it sounds hilarious and retarded, but it would be something that we could have up and running in a month. Work from there.

[kappa]

I think the easiest option would be a Java interpreter in Javascript. I know it sounds hilarious and retarded, but it would be something that we could have up and running in a month. Work from there.

That would be the most slowest thing evaaaa
GWT seems like the best way to go IMO, it works really well already.

[princec]

When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job  but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

Cas

Games published by our own members! Go get 'em!

[lhkbob]

When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job  but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

Cas

Perhaps we should just make a new browser that has proper applet and java integration

[xinaesthetic]

Perhaps we should just make a new browser that has proper applet and java integration

Perhaps we should make a new society where everyone holds hands and smiles and there's never any problems and everything's just peachy. 

[gouessej]

Sorry to refresh this thread. I have a meeting tomorrow and I will have to speak about JOGL, they would like to know some things about the future of JOGL. Can someone tell me at least how many people go on fixing bugs and maintaining the whole library? Are Sven Goethel and Michael Bien participating to this project?

[Cork]

@gouessej  Did you manage to get any info, or is the lack of activity over the last month an indication of things to come?

[aNt]

*head in hands*

[kaffiene]

When I went to interview at Google I talked with some engineer or other about Chrome and how I'd like to embed a JVM in it as the core clientside execution engine. Needless to say I didn't get the job  but I still think it'd probably be the utterly brilliant panacaea we all want - high speed execution built in to every browser with proper language tools and support behind it, with hardware acceleration and DOM integration out of the box...

Cas

Yes, I agree entirely.  I code a lot of Javascript (and server-side C#) at work, and it's really shit.  Well, the JS is, the C# is ok.  Having a JVM in browsers would rock - especially if you could produce bytecode from whatever language you wanted.  Awesome solution.

[xinaesthetic]

http://en.wikipedia.org/wiki/Google_Native_Client

Games published by our own members! Go get 'em!

[princec]

There are a ton of reasons why I moved away from native code compilers.

Cas

[xinaesthetic]

I'm not suggesting that's an ideal way forward, but it is interesting that Google seem to be pushing a bit in that direction.

[princec]

Especially as they are doing their absolute best to totally kill all native plugin code with Chrome OS.

Cas

[xinaesthetic]

All apart from their own.

[gouessej]

@gouessej  Did you manage to get any info, or is the lack of activity over the last month an indication of things to come?

Yes I manage to get info. JOGL is in a good health, don't worry  According to bienator:
"The JOGL2 public api is IMO fairly complete "only" bugfixing and patching has to be done, but I really don't know a release date."

JOCL seems interesting too 

[xinaesthetic]

"The JOGL2 public api is IMO fairly complete "only" bugfixing and patching has to be done, but I really don't know a release date."

JOCL seems interesting too 

Actually, I do really want to be able to access Cg annotation values... still waiting for feedback on that.

JOCL does seem interesting; ScalaCL potentially even more so...

[gouessej]

Actually, I do really want to be able to access Cg annotation values... still waiting for feedback on that.

Michael Bien seems very busy with JOCL, maybe talk about that to Sven.

[xinaesthetic]

mbien did respond to a previous thread of mine on the subject, commenting that it was Sven's area and that he was on holiday... I gave it a gentle bump when Sven got back, but maybe a PM wouldn't do any harm.

Thanks.

[Cork]

sorry to bump again, but I have a feeling that this thread is still very relevant to the future of JOGL2 and remains mostly unanswered.  (deployment issues, magic certs, LWJGL merge, newt, es2, competing against WebGL?)

Another month has gone by, and there is no clear future laid out for JOGL2.  Sven I appreciate if you are working on this behind the scenes, but is was back in october/november when JOGL was declared alive and kicking after Sun pulled the plug.  I haven't really seen any public progress since then.  Ok I know there is a git repository, but there is no community around that.  We are still sat here on sun bb's waiting for news.

Anyway I've spent the last month playing around with GWT.  Already there are 3 Java bindings down to WebGL.  Is it worth at this point to consider using the same approach for JOGL?  I like the JOGL API's, and I don't see why gluegen couldn't be generating the WebGL ES2 binding for us?  JOGL has the advantage of maturity, and quite a good following...

I just want to get a feeling for the future of Java OpenGL in the browser.  When I see how fast things are progressing with WebGL, it makes me wonder if JOGL2 has any future at all, unless that is the binding changes.

http://learningwebgl.com/blog/
http://code.google.com/p/gwtgl/

[CommanderKeith]

At least the excitement around webGL might mean that the graphics card manufacturers pay more attentention to testing their drivers with OpenGL rather than just Direct3D.

[Momoko_Fan]

You guys are being quite pessimistic.. Really though, deployment issues don't matter much. Look at runescape for example, pretty much the most popular web mmo, do you think all these certificates and deployment things stopped them? Hell no. They have a goal and are working toward it.
Users are ready to accept these certificates or what not if they get to play a quality game. So what you should be working at was making a quality game and not worrying about all this webgl/google/whatever "World Domination" crap.

[gouessej]

sorry to bump again, but I have a feeling that this thread is still very relevant to the future of JOGL2 and remains mostly unanswered.  (deployment issues, magic certs, LWJGL merge, newt, es2, competing against WebGL?)

Another month has gone by, and there is no clear future laid out for JOGL2.  Sven I appreciate if you are working on this behind the scenes, but is was back in october/november when JOGL was declared alive and kicking after Sun pulled the plug.  I haven't really seen any public progress since then.  Ok I know there is a git repository, but there is no community around that.  We are still sat here on sun bb's waiting for news.

Anyway I've spent the last month playing around with GWT.  Already there are 3 Java bindings down to WebGL.  Is it worth at this point to consider using the same approach for JOGL?  I like the JOGL API's, and I don't see why gluegen couldn't be generating the WebGL ES2 binding for us?  JOGL has the advantage of maturity, and quite a good following...

I just want to get a feeling for the future of Java OpenGL in the browser.  When I see how fast things are progressing with WebGL, it makes me wonder if JOGL2 has any future at all, unless that is the binding changes.

http://learningwebgl.com/blog/
http://code.google.com/p/gwtgl/

We have already answered to these questions as far as I know. Why do you speak about a binding for WebGL whereas it is already possible to use JOGL 2 in applets? The magic certificate will no more work, there won't be any merge with LWJGL as Michael is not interested by this.

[lhkbob]

... there won't be any merge with LWJGL as Michael is not interested by this.

This is news to me (and not very happy news at that).

[Cork]

We have already answered to these questions as far as I know.

really?  the lack of certificate is news to me, and so is the decision regarding LWJGL.  But both are bad news items   can you point me to the discussion please?

Why do you speak about a binding for WebGL whereas it is already possible to use JOGL 2 in applets

Many reasons I already mentioned, but mostly because it doesn't require a client side plugin(Java), or certificate, and is pretty much instant startup.

[princec]

If anyone's interested, you can implement JOGL in terms of LWJGL. Just not the other way round.

Cas

[bienator]

Well, I don't believe I said it this way. But what i said is that I am in favor of choice since not having a choice as "consumer" is always bad. But JOGL is BSD anyone can do anything (s)he wants with it... merge, fork, sell..

I am working now most of the time with CL (check out some demos if you like; screenshots) AND I am writing on a bachelor thesis... so don't expect major news regarding jogl from me the next few month.

WebGL:
the last conversation i had with the guys of one of the mentioned projects is that using JOGL's interfaces was on there plan to investigate and they don't see any showstoppers, but this was around one month ago.

If anyone's interested, you can implement JOGL in terms of LWJGL. Just not the other way round.

generating static methods is one single flag in gluegen (i believe its even on by default). JNA is far more convincing as an alternative as the generator of LWJGL for me.

[Cork]

WebGL:
the last conversation i had with the guys of one of the mentioned projects is that using JOGL's interfaces was on there plan to investigate and they don't see any showstoppers, but this was around one month ago.

I asked on here about using the JOGL API's and the guys didn't seem to be aware of JOGL at all...
http://www.khronos.org/message_boards/viewtopic.php?f=46&t=2353&start=0

I'm now playing with GWTGL http://gwtgl-examples.appspot.com/ and so far I quite like the approach of keeping a binding and wrapper implementation separate.  This might make adopting JOGL2 API an easier task, but I haven't heard from the guys for a couple of weeks.

PS the OpenCL stuff is looking Very nice!

[gouessej]

I asked on here about using the JOGL API's and the guys didn't seem to be aware of JOGL at all...
http://www.khronos.org/message_boards/viewtopic.php?f=46&t=2353&start=0

I agree with what you said. If you find a solution to use JOGL with WebGL, let us know. However, I fear that WebGL won't be fast enough for resource hungry OpenGL games

[AI Guy]

generating static methods is one single flag in gluegen (i believe its even on by default). JNA is far more convincing as an alternative as the generator of LWJGL for me.

Michael,
I know there are a lot more calls in OpenGL vs OpenCL,  but I would consider JNA for JOGL as well (I do not actually know what LWJGL is).  Is the CPU constantly pegged on all or any of the games made using JOGL?  If not, then there might be high price being paid for static calls, and the drop off using JNA negligible.  Even if this was the case, I think not nearly all of it is being tied up in actual Native calls.  Aren't Display Lists an effective mechanism for reducing the volume of calls anyway?

Gluegen is something that needs to be understood, maintained, & you actually have do builds on all the platforms that need support (or maintain cross compilers).  This effectively means that JOGL is being built / maintained from the ground up.  Using JNAerator to build your JNA bindings frees up resources to actually work on the high level bindings for JOGL 3.0, or whatever.  There's JNA support underneath.

Looks like you will be out of school in the not too far future,  reducing the JOGL footprint could allow you to have a hobby project without comprising either it or work.  Olivier manages JNAerator & projects derived from it, specifically JavaCL, & I know he is out of school.  (For other readers who have Nvidia 195 or higher you could run JWS demos from http://code.google.com/p/javacl/, if interested)

I am only bringing this up now on page 6 of a marathon thread, because I thought it might be a blind spot.

Jeff

[gouessej]

Michael,
I know there are a lot more calls in OpenGL vs OpenCL,  but I would consider JNA for JOGL as well

It is a very bad idea as JNA is slower than JNI (JNA uses Microsoft Platform Invoke under Windows which is noticeably slower than the path used by JNI) and GlueGen works reliably. I highly discourage Michael to use JNA instead of GlueGen. I'm sorry, I'm a quite old JOGL user and I will refuse any use of JNA in it.

Looks like you will be out of school in the not too far future,  reducing the JOGL footprint could allow you to have a hobby project without comprising either it or work.  Olivier manages JNAerator & projects derived from it, specifically JavaCL, & I know he is out of school.  (For other readers who have Nvidia 195 or higher you could run JWS demos from http://code.google.com/p/javacl/, if interested)

I am only bringing this up now on page 6 of a marathon thread, because I thought it might be a blind spot.

Jeff

Yet another Java OpenCL binding... I don't really understand such fragmentation as it is always the same history. There were at most 5 Java bindings of OpenGL some years ago and now there are only 2 bindings. How many people will waste their time in maintaining very very similar libraries instead of building 1 or 2 tougher ones? JOCL is Michael's thesis project, he has to make any decision concerning it (so I won't have the last word anyway) but I rather encourage the author of javacl to join the JOCL project or at least to use GlueGen instead of JNAerator.

JOCL has some degree of interoperability with JOGL so keep it up Michael A back port in JOGL 1.1.1 could be interesting for me but there is no hurry about this.