Catch 22 for jogl

This is like the case with KDE4 crashing X server or drawing garbage. Users wrongly blamed KDE, but the thing is that X should never crash (or have garbaged non-related portions of screen) because of application, if it does it’s clearly not application fault but X/drivers.

Or more explicitly: check what is the cause and get it fixed in the opensource drivers, for proprietary drivers you can report the bug (ideally after narrowing the problem to some call or so). Or you can just buy NVIDIA :slight_smile: overally they seem to have better support with their closed source driver, especially for highend 3D.

At first, I use KDE 3.3 and KDE 3.5, not KDE 4. Why don’t I have the same problem when leaving an application using AWT/JOGL that restores cleanly the display mode?

[quote]When returning to windowed mode from an exclusive full-screen window, any display changes made by calling setDisplayMode are automatically restored to their original state
[/quote]

Why didn’t you put this bug into the bug list?
http://kenai.com/bugzilla/buglist.cgi?product=jogl&order=Importance&limit=25

Though that random distraction is detracting from some underlying feelings and tensions in the Java community about how the whole situation has been over the last few years.

It goes something like this:

There was a perfectly good open source OpenGL library for Java project called LWJGL, about 8 or 9 years ago now. For reasons poorly explained, Sun threw a big NIH wobbler and announced somewhat unexpectedly a competing and considerably inferior set of bindings called JOGL (and JOAL, again for reasons totally unexplained), which took a pretty long time to get up to speed reliability and features wise. At the time, somewhere on these forums, the official reasoning was some guff about security and integration with AWT; rather than take advantage of the existing huge amount of work that had gone into LWJGL and asking us if we could make a few little changes to accommodate some new security and integration features, somehow it was reasoned that it was a profitable waste of someone’s time to just write a complete duplication of effort and create JOGL.

Life went on, JOGL didn’t go all that far (look at the relative release frequency), LWJGL continued to be used for most of the serious 3D work going on in the world. Lots of people jumped on the JOGL bandwagon though because it was allegedly officially endorsed by Sun.

JOGL 2 gets announced, woop-de-do, which appeared to be more of the same. LWJGL carries on as it always has.

Then Oracle turn up, Sun ditch JOGL 2 like they’re holding a steaming turd for absolutely no well explained reason, and it becomes yet another little open source pet project for someone in their spare time, just like LWJGL, except without the rather large team of backers and lengthy term behind it, and very intermittent support. At this point people who chose JOGL because of its alleged official endorsement should probably have been questioning their reasoning and decision, as we pointed out way back when, it is probably a safer bet to go with a very long established open source project that’s under active development than some brand-new API from a company with a history of screwing things up on the client. LWJGL carries on regardless without so much as batting an eyelid.

There was a silver lining to all this stupid duplication cloud which was the little bit of competition we actually got from having JOGL around spurred the LWLGL team on to leapfrogging JOGL’s functionality.

Now the thing is we’re all in the same boat now with the Oracle fiasco. It’s reasonably clear that Oracle don’t care much for the client by their diversion of resources away from JOGL 2 and JavaFX. In fact we’re all feeling really really sketchy about the whole future of Java, not just on the client, after years of broken promises from Sun about deployment options, and now the new and even less trustworthy masters are probably going to ruin the situation further.

Cas :slight_smile:

I can almost feel the apoplectic outrage building.

Whilst I wait for the bomb to go off, I’d just like to say well done Spasi for just saying it like it is.

It’s not just the LWJGL and JOGL teams time that has been wasted all these years - it’s also everyone else’s time who has had to make some stupid pluggable renderer rubbish to get their projects to work on both LWJGL and JOGL. I’m looking at you Monkey Engine, and all the other similar projects. And then there’s all the people who’ve tried JOGL and had to migrate everything over to LWJGL when JOGL’s not worked out. What a colossal, pointless waste of time, just because somebody somewhere was too proud to have accepted a community driven project into the JDK.

And while I’m at it I’m bloody pissed off that we’ve done all this work for the Java community and yet our expertise has never in the end paid off in terms of contracts or paid work of any kind. Grrr. But that’s just my own personal axe to grind.

Cas :slight_smile:

What do you mean exactly? I understand the rest of your explanation even though I was not yet using Java in 2000. I think that JOGL is almost only an OpenGL binding, it is not a surprise that a different road (in comparison with LWJGL) has been taken, JOGL users don’t expect the same thing from JOGL than LWJGL users from LWJGL. Some people using JOGL in some corporations told me “Julien, we only need an OpenGL binding in Java, we don’t need OpenAL stuffs, etc…”. People have different needs. Some work has been done on JOGL too but with more modest and different aims. I see nobody ruining anything, Sun does not take care of JOGL. I remind you that JOGL 2 includes Newt and a binding of OpenGL-ES, it is not something minor on my view.

I mean that Oracle are far, far more sinister than Sun. They’ve got far, far, more money and the more money an organisation has the less it has to care about anything they do until such time as they squander it (look what happened to Sun after the dot com bust).

Some corporations saying “Julien, we only need openGL bindings” might well have just ignored the OpenAL APIs in LWJGL which are in separate packages. None of it is necessarily tightly integrated. Are these guys so lazy they won’t even just delete packages they don’t want? Do we have to make special downloads from sourceforge to remove the extra 250kb of binaries they don’t want?

And as for OpenGL ES… there is a reason why there is no LWJGL ES binding (yet). It’s because nobody has any use for it. There are no OpenGL ES devices that can run Java fast enough to it be even worth bothering. LWJGL was a community-needs driven project, and there just simply is no demand for an ES binding. It’d be nice if, say, Google had decided to use an existing GL binding for their Android platform but no, they went ahead with another of those NIH wobblers and made their own for no good reason other than they have far more money than sense and a lot of underutilised engineers sat arond twiddling their thumbs in some giant CVS sandpit.

And NEWT? What the hell is NEWT? Who needs NEWT? It’s supposed to be out of the box GL binding. How hard can that be?

This whole situation is just shameful.

Cas :slight_smile:

As far as I know, the JOGL renderer of JMonkeyEngine 2.0 had stayed in a very bad state a lot of time (only a few people including me invested some time in improving this renderer) and the JOGL renderer of Ardor3D works fine. I admit such mechanisms to support both bindings are time-consuming to design and to implement but what do you suggest?

[quote=“princec,post:46,topic:34594”]
Sorry, I was not a Java programmer in 2001. Sun refused LWJGL only because it was a community-driven project, didn’t it?

An OpenGL ES binding could be useful in a way. After pushing for a JOGL/LWJGL merge, my next plan is to get Firefox/Webkit/whatever developers to give us access to a Canvas element’s GL context. We’re still 6-9 months away from seeing stable/final WebGL implementations, so there’s time. Imagine hidden Java applets running 3d content on lightweight HTML elements, which in turn are composited by the browser’s engine. Java2D/JavaFX will never let us do that, but who cares, browser developers have seen the opportunity that Sun has missed for years. Javascript isn’t going to catch-up with Java performance any time soon, it would be godly if we could do something like that around the time Java 7 is released.

Anyway, WebGL = OpenGL ES, one extra reason to merge with JOGL.

Want more reasons? How about the GPGPU crowd? It’s already established that we aren’t going anywhere with writing GLSL shaders. No problem, OpenCL is already out. Now lets wait for Spasi/Bienator to create the bindings for us… oh really? Are there going to be 2 bindings again? Hell, no.

We need to join our resources and stop the fragmentation. Both JOGL’s and LWJGL’s developers have limited time and limited resources. Why have 2 developers doing twice the amount of work, when you can have them both on the same boat, doing different stuff, with better integration, more hands to work on bug fixes, creating a uniform product that solves everyone’s problems?

Before I forget again, about the different APIs. Like Riven said, it’s trivial to generate both sets of bindings. Pick the one you like and do your work. The importance here is to have one set of native binaries, unified features, unified bug fixes.

[quote=“Spasi,post:50,topic:34594”]
There can’t be unified bug fixes if the both source codes are kept, there will be one of the both that will actually disappear in the merge. Merging both APIs is not a bad idea but I don’t see how to do this concretely.

Edit.: I don’t want to waste some nice helper classes of JOGL too. What about the interoperability with AWT/Swing?

I’m seconding you on this one. Java on the desktop is cursed…
A propos contracts and paid work: how about maximizing your OpenGL experience by embracing Android (or even the iPhone?..)

That was my main reason.

Another reason for choosing JOGL over LWJGL was because the ‘G’ in its name stands for something other than ‘Game’. I was rewriting my CV/Resume at around that time, and I decided that, if the situation arose, I would be more comfortable in a job interview talking about OpenGL Bindings than about Game Libraries. (And if that seems stupid then you haven’t been interviewed by some of the people I have. :stuck_out_tongue: )

Which makes me wonder for how many academic/business projects the JOGL versus LWJGL argument boiled down to simply “official product” versus “for games”.

Anyway, I’ll probably be jumping ship to LWJGL in the near future. The number of people speaking-up for JOGL in these forums seems worryingly low…

Simon

There really isn’t a great deal of difference. As julien pointed out there are plus points for both sides, merging the two projects doesn’t mean losing any features, just that they’re all supported from one place.

Go Spasi, Go!

Kev

Just as an anecdote, the game company I work for chose JOGL back in 2002; I believe that no-one making the decision had heard of LWJGL.

Hm it is of slight concern that LWJGL does not appear on the first page of a search let alone at the top for “Java OpenGL binding”.

Cas :slight_smile:

Thats cause it’s a game library, not an OpenGL binding :slight_smile:

Kev

http://www.google.com/search?hl=en&q=java%20opengl%20game+-site%3Aexperts-exchange.com&btnG=Search

1st hit

Yes I would have saved some time if JOGL had something like Mouse.setGrabbed() but JOGL has some nice helpers (that would be easy to port). I have just tested anew some demos of LWJGL under Linux and it works better than I expected (I have to confirm the results on crappier machines). If Spasi achieves to preserve the reliability of JOGL especially under Linux, I will have no objection but I really fear that project leads to a phagocytose of JOGL by LWJGL.

Anyway, in the worst case, we could keep 2 separate OpenGL bindings but have a common OpenCL binding, why not?

However, I’m not reassured about the project of unifying the both APIs and I’m already looking for sponsors in order to have some engineers (at least one) maintaining JOGL during a part of their full-time job.

Sun is gone but JOGL is not dead. A colleague of mine who is an OpenGL expert told me that too much corporations are using it. If the project of unified binding fails, JOGL will still be there.

[quote=“dishmoth,post:53,topic:34594”]
Some people make a great job on JOGL but they are more discreet. Please go on using JOGL, there is no need of jumping ship.

Sun already proved it doesn’t give a damn about how many corporations are using it, as it’s now in the hands of volunteers, so it can very well die, and relatively fast too. I’m not saying it will, I’m just saying that it is more likely to die than LWJGL.