Is there any links to a thread that has comparisons between these two api’s? i wish to produce a table that shows differences, advantages, disadvantages of each language, as i am using lwjgl i am hoping that it has more advantages. oh yes and the context of this question is in relation to making games but all advantages and disadvantages are welcome, thanks guys
Take a look at http://jogl.dev.java.net/JOGLGlueGen.pdf , slide 4. It has a table which compares significant attributes of LWJGL, GL4Java, Magician, and JOGL. This was presented a while back (May 2004) to the JSR-231 and 239 expert groups.
Isn’t it just slightly out of date? I though LWJGL now had the idea of contexts so you could happily rendering into AWT/Swing…
Meaning that they are apparantly the same from the slide 
Except of course they’re not.
Kev
Although LWJGL can be used with JOGL, there is no direct LWJGL method for creating LWJGL contexts in AWT components. Soon to be rectified I think.
Cas
Why would anyone have to use LWGJL with JOGL. They both do same level of opengl java wrapping, so feels kind of weird.
“Soon to be rectified…” meaning JWLGL team is working on to make it a first class citizen in Java Swing/SWT world?
Gregory Pierce has come up with a LWJGL-in-a-JPanel thingy, and I’m thinking about how to do a first-class LWJGLAWTCanvas component descended directly from java.awt.Component.
Cas
I’ve been trying to get a serious, complete, lengthy, accurate comparison of the two for over a year now :(.
With the new JGF, I’ve had comments from quite a few people that suggest an automated comparison table between technologies would be useful.
What do you think about a page where you could do something like:
- Click “add new feautre”
- Type in description + details
- Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)
?
How much detail would be needed? Any extra fields? Obviously, the more detailed the features could be, the less description, the better (lets viewers just choose the particular features they’re interested in).
[quote]3. Select the feature-type from a drop-down (so that it gets compared like-with-like with other techs)
[/quote]
There’s no way you’ll be able to come up with a feature list that’s detailed enough but still usuable! :
I’ve never found two pieces of software (or hardware) that can be easily compared using bullet-point lists. One-line descriptions are rarely enough to enable people to understand the ramifications of an API difference. And trying to get rival developers to agree on common feature-types or the wording of each API’s entry… shudder
Might be better to just have a specific area where user-described API comparisons can be posted - a couple of paragraphs from three different people should be enough for most people to understand the differences.
…is my default expectation too. But, since the other thing doesn’t seem to work (c.f. below), and JGF is heavily moderated, I’m holding out hope that some compromise could be done that is useful even if it has obvious imperfections.
Perhaps…if users could propose features, and a moderator ACCEPT’d those that they thgought applied, and the JOGL, LWJGL, etc authors could fill in their own 200 words on each “feature” proposed this way?
So far it’s proved impossible to find people of even approximately equivalent knowledge about the different API’s who are also willing and also able and also actually do it to do this.
I have a fairly good working knowledge of both APIs if you need any help from that angle.
[quote]…is my default expectation too. But, since the other thing doesn’t seem to work (c.f. below), and JGF is heavily moderated, I’m holding out hope that some compromise could be done that is useful even if it has obvious imperfections.
[/quote]
Well, if you think it’ll work - go for it!
Perhaps I’m being a little too negative here. It’s not necessary to get everything absolutely 100% concise - any central source of information on relative API merits will be a good thing, even if it doesn’t quite apply in some circumstances.
Hello blahblahblahh
Actually the only feature you’ll find in JOGL which is not present in LWJGL is the embedding with AWT. If you don’t need that feature, I suppose you won’t find the killer feature in one or the other library that you search for.
All other things are more or less a matter of opinion. JOGL is more modular. You need to download more libraries for sound and control (e.g. joal and jinput).
Also JOGL is more instance oriented. That means you get more the feeling of OO in JOGL. Even the fact that JOGL talks about games, it’s also useful for other things e.g. in Swing.
LWJGL puts everything in one distribution. It seems to me more like a “best of breed” library for games (graphics, sound, control in one place). It’s developed for games and nothing else in mind. You’ll get everything you need from one place. LWJGL uses heavily static methods (as far as I see that). This looks more like C and that means also the layer in LWJGL is slightly thinner than in JOGL. Thats cool for all those who need that transparent approach.
Fact’s are: Both libraries are well developed, both have reached mature stability and both have enthusiastic support from their developers.
I suppose you search the library for a game. 
Games usually don’t have the requirement for a long term maintenance track.
So I think you can’t go wrong. Just use the library that looks useful for you and that supports your programming style.
Sometimes it’s better just to begin…
Cheers
Bössu
[quote]Hello blahblahblahh
[/quote]
FYI, I know and use both. This isn’t for me, but for other people ;).
I can think of a couple differences that to me are much much bigger than that. See? This is why a feature guide would be nice ;D.
…apart from all the other differences you don’t seem to be aware of.
Which is why a side-by-side compare, from the horse’s mouth of each camp, would be handy.
+1 difference: JOGL windowed does not steal a mouse cursor. LWJGL windowed steals all your mouse cursors.
EDIT: after two following posts, I stand corrected. Some readymade copypaste code did it, so dont blame me ;D
That doesn’t happen on my machine… if it ‘steals the mouse’ you have probably done this: Mouse.setGrabbed(true);
edit: typo.
correctomundo - LWJGL doesn’t “steal” a cursor - only if a developer has requested to do so by calling Mouse.setGrabbed(true);
Hello blahblahblahh (and others )
I see, the discussion is beside of “only” OpenGL, OpenAL, Input-Binding.
Well, feature-lists… It would be really cool if there would be a list which helps to find the right solution for a problem, hands down.
Cheers
Bössu
Briefly:
In functionality terms, LWJGL = Hires Timer + JOGL + JOAL + JInput - AWT; LWJGL is not directly integrated with AWT but JOGL is, which means LWJGL is less of a candidate for CAD/CAM applications right now
In API terms, LWJGL exclusively uses direct ByteBuffers to pass data to native code and we have removed methods that are just C shortcuts for efficiency; JOGL also uses heap arrays, for convenience at the expense of efficiency and high performance programming techniques.
In dependency terms, LWJGL is totally self-contained; JOGL depends on AWT
In size terms, LWJGL is considerably smaller.
In simplicity terms, LWJGL is much simpler than the JOGL/JOAL/JInput combination - we have one focus, which is games, and that’s allowed us to axe tons of complex setup code.
Cas
Also:
-
LWJGL is miles ahead in terms of reliability and compatibility. I couldn’t seriously expect any professional game to be satisfied with the current reliability of Jogl.
-
Jogl’s display creation is clumsy, awkward and not nearly as flexible as LWJGL’s. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.
-
Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.
-
Jogl allows for GL contexts that can be resized.
-
Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there’s now a proper swapBuffers interface now?
-
Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn’t suffer from these problems. Realistically it performs so slow its just not practical for anything useful.
-
Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).
[quote]Also:
- LWJGL is miles ahead in terms of reliability and compatibility. I couldn’t seriously expect any professional game to be satisfied with the current reliability of Jogl.
[/quote]
I don’t think this is a fair assessment of the JOGL project. 1.1 b08 (and in particular the revised single-threaded workaround) has addressed basically all open stability issues, most of which were ultimately caused by OpenGL driver bugs exposed by multithreading. If you are still seeing stability issues on a given vendor’s card with JOGL, I would appreciate it if you would file a bug.
[quote]- Jogl’s display creation is clumsy, awkward and not nearly as flexible as LWJGL’s. Also, when it goes wrong it tends to core dump instead of throwing anything you could recover from.
[/quote]
Could you provide an example of how LWJGL’s display creation is “more flexible” than JOGL’s? The current JOGL source base does enforce a factory method for the construction of OpenGL widgets, but this restriction will be removed in the forthcoming JSR-231 API implementation.
[quote]- Jogl has the object access to GL, LWJGL uses the static interface. In theory that means Jogl has the handy-dandy composable pipeline. In reality both end up doing error checking (LWJGL substancially more on buffer args) but Jogl makes you pass round an annoying GL object constantly.
[/quote]
JOGL supports concurrent rendering to multiple OpenGL contexts; LWJGL does not. If LWJGL used an object and per-context function table to represent OpenGL function pointers than it could more easily support multithreaded OpenGL rendering. As it stands the native code for LWJGL would have to change substantially and do a lookup in thread-local storage per OpenGL function call in order to support multiple contexts. See the GLEW library for more information on how to do this in straight C code.
[quote]- Jogl has a clumsy Animator interface for actually displaying anything that forces you to do things how it wants. Although I believe that there’s now a proper swapBuffers interface now?
[/quote]
JOGL has exposed a swapBuffers API for nearly a year.
[quote]- Both are going to have heavyweight vs. lightweight issues when embedded in a Swing app. Theoretically Jogl has a lightweight display that doesn’t suffer from these problems. Realistically it performs so slow its just not practical for anything useful.
[/quote]
JOGL 1.1 b08 adds hardware acceleration for its GLJPanel widget, and there are fixes in the CVS repository which will be present in 1.1 b09 which address performance issues on ATI cards. The GLJPanel is now fast enough and featureful enough for application use.
[quote]- Both have almost useful documentation. But the LWJGL examples/tests do provide a working base. By contrast the Jogl demos seem to be constantly out of sync everytime I look at them (and consequently broken).
[/quote]
This has not been my experience. The JOGL demos are tested on all platforms before each major release of the library and consistently show off the most advanced features of OpenGL like vertex and fragment programs.