Catch 22 for jogl

Under Linux and Mac, I confirm that JavaFX uses JOGL 2 but I don’t know exactly which part of it, it is used at least for the GLSL shaders.

Thanks for the confirmation.

If JavaFX uses JOGL2, then how can JOGL(2) be an abandoned project
by Sun as I’ve read from some posts around the web? And does JavaFX
maintain its own private branch of JOGL2?

.rex

Sun uses only a subset of JOGL 2 and I have no information about its own private branch, maybe some guys in the Java2D team could answer you. Anyway, I assume this corporation knows that JOGL 2 will be maintained and it will benefit of the bug fixes of the community for free.

Sigh, I guess the whole merge LWJGL and JOGL idea has been abandoned already…

I know I haven’t contributed that much since I joined this community 7 years ago, but if you were to take my advice for once, now is the time:

STOP THIS CRAP.

We all have much more important things to worry about than having to develop, maintain and debug 2 different OpenGL bindings. I know there are differences in features, API design or context initialization on whatever linux distro gouessej is using. These are all STUPID TECHNICALITIES. As a long time community member, as a long time OpenGL developer, as a long time LWJGL contributor, I’m asking you to drop whatever you’re doing and try to work something better out. We can do this with a result that will keep every JOGL/LWJGL user happy, we can do this with less bugs and more features. Enough with this waste of time and effort duplication.

i don’t know (I am no sun employee). It looks like a fork of jogl 1.x.

choice is a good thing. As you already said both apis have differences in public api design, build, java 1.4 or 1.5 compatibility and even in the usecases. LWJGL is focussed on games and is more than GL, JOGL is “just” a OpenGL binding.

Its to late for a merge without killing one of them. Its like merging eclipse with netbeans.

I don’t believe this is the case. You can use one code-generator to generate both APIs, with the same bugfixes.

LWJGL is not focused on games, and hasn’t been for a long time. It’s just a general hi-perf direct media layer. Medical imaging, CAD/CAM, TV graphics etc. are all what it’s about.

Cas :slight_smile:

TV graphics? Could you elaborate on that a little? I wasn’t aware that
there’re TVs that can run Java, let alone OpenGL. Or did you mean
broadcast graphics content?

.rex

Live TV broadcast for APTN.

Cas :slight_smile:

Hi!

At first, JOGL is not a crap. I wanted to keep cool but enough is enough! I would like some people to avoid advertising LWJGL in the JOGL section please, this has to come to an end now. Spasi, I have had fewer problems under Windows than under Linux with LWJGL but it does not mean that I consider LWJGL as a reliable OpenGL binding even under Windows. When a Java game crashes, whatever the OpenGL binding it uses, it is bad for Java, not only for the specific OpenGL binding that is in use.

Maybe we could reduce time and effort duplication by maintaining a single OpenGL binding but:

  • the best way of convincing JOGL users does not consist in provoking us by advertising LWJGL in the JOGL section and by the way, you only prove bienator is right, a merge would kill one of the both API, JOGL for sure
  • suggesting that considerations around Linux are stupid and then that the support of Linux is not important is not a good way of convincing JOGL users who need for personal and professional use a really excellent support of this family of operating systems. Haven’t you noticed that some people (not only me) have tried to use JOGL on Unix-like (BSD, OpenSolaris) and Linux operating systems?

Riven’s suggestion is interesting on my view but you have to give us some guarantees about the support of all major operating system families. I don’t want to always get the same answer when I find a bug under Linux “No it is a driver bug” (I know it is sometimes true but it cannot be always invoked on a particular operating system, it is not credible).

Anyway, maybe some JOGL very active users and some LWJGL very active users could try to provide a draft describing a unified OpenGL/OpenGL-ES binding for Java by taking into account the preoccupations of both communities and then, people here could vote, I don’t want to impose any decision as it would not be democratic but a precondition is that we pacify the situation by avoiding provocations in the both directions. If you think bienator is wrong when he writes that it is too late for a merge, prove it.

Perhaps this is an uneducated response, but I think one of the benefits of JOGL vs. LWJGL is that it seems better suited for using multiple windows. I know LWJGL has the Display static class and I think an AWTGLCanvas, but everything I read focuses on just the Display class, which allows for only one surface (which is fine for fullscreen windows).

Anyway, if I’m wrong I’d love to be corrected. If not, having multiple window support would be a great feature for a combined opengl binding. I’d have to say my vote would be for a unified binding, if only so that everyone uses the same thing. Then everyone’s questions could be answered in one place, instead of 3 places (this jogl board, the lwjgl board here, and the official lwjgl forum).

AwtGlCanvas is old school now, the new way is Display.setParent. It’s not too hard to use that to share a single OpenGL context between several different canvases (which may or may not be on different top-level windows). I do this for my map editor and it seems to work nicely.

Hi gouessej,

You should go back and re-read my post, because I didn’t say that JOGL is crap. I said that duplication of effort and wasting time is BAD BAD BAD. If I thought JOGL was crap, do you think I’d even care to type my previous reply?

I won’t even bother to defend myself or LWJGL’s features or LWJGL’s support for multiple OSes. There are many serious people in this forum that know exactly what both LWJGL’s and JOGL’s strengths and weaknesses are. It’s all beyond the point though.

I hope this is the last time I have to reply to the forum’s troll.

[quote="Spasi,post:34,topic:34594"] I hope this is the last time I have to reply to the forum's troll. [/quote] Hardly. Most of us (that have been here a while) have already barked up that tree. Just force yourself to stop replying. I've gotten to the point where I just read his posts as if they are jokes. It turns out he's pretty hilarious.

“enough is enough!” lol ::slight_smile:

Thanks, that’s just what I was looking for.

The screen capture I sent some years ago to princec to complain about the lines drawn on my task bar and my whole desktop after leaving an application using LWJGL is not a joke. [quote="Spasi,post:34,topic:34594"] You should go back and re-read my post, because I didn't say that JOGL is crap. [/quote] Ok sorry I misunderstood your post. [quote="Spasi,post:34,topic:34594"] Then you understand that some people want to go on using LWJGL and some other people want to go on using JOGL. That's why it would be difficult to "kill" one of them or to merge the both.

I think I told you at the time: your crap open source drivers were the problem. How we could possibly have anything to do with what’s drawn outside of our graphics context is beyond me.

Cas :slight_smile:

I was able to reproduce this bug with the ATI Radeon X1950 Pro with the proprietary driver too. I will try some of your demos on another computer with an Nvidia Quadro FX 3450 with a proprietary driver under Linux to check if it is reproducible with the latest version of LWJGL (2.2.1?).

Broken proprietry drivers also. There’s very little QA goes into Linux driver testing. It may be a bug at a more fundamental level than that, like the X subsystem or something. Either way - we have no access to any other elements of your desktop.

Cas :slight_smile: