JOGL and OpenGl Differences

Hi all,
In finalizing our basic JOGL chapter, I want to check to make sure we hit all the significant JOGL/OpenGL programming differences.

For those of you that have hacked out any JOGL code, what was a difference between straight OpenGL code you’ve used/written/seen?

We have the obvious, such as ByteBuffers, but I would like to hear some that maybe tripped you up to included.

After a few posts I’ll post our standing list, and maybe this can be folded into a FAQ somewhere.
Thanks to all!

Its not really Java/Jogl specific, but lots of people seem to get tripped up with the whole multi-threading thing, especially trying to tinker with GL state from event handlers of some form or another.

Handling input
Loading textures
Handling the GL.,GLU.,GLUT., etc.

[quote]Its not really Java/Jogl specific, but lots of people seem to get tripped up with the whole multi-threading thing, especially trying to tinker with GL state from event handlers of some form or another.
[/quote]
Hmmm, interesting
We have two seperate projects using JOGL, and never ran into the multi-threading issues, i.e. calling gl.doSomething(), from a event thread because

  1. The one project doesn’t get UI events
  2. Both projects make calls to retained data objects that a renderer does OGL work to.

So I’m very curious, what examples/projects have other people bumped into this problem on, because we weren’t planning on same much beyond, “Must access JOGL operations on the same thread” or the more eloquent “JOGL isn’t thread-safe like many Collections”

[quote]Handling input
[/quote]
Do you mean the same event input as Tang, or like Jinput?

[quote]So I’m very curious, what examples/projects have other people bumped into this problem on, because we weren’t planning on same much beyond, “Must access JOGL operations on the same thread” or the more eloquent “JOGL isn’t thread-safe like many Collections”
[/quote]
It just seems to have cropped up on the forums a few times, most C++ tutorials don’t tend to mention this since they end up doing everthing in the same thread anyway, yet its very easy to forget that you happen to be within a different thread in a message handler.

Easy enough to avoid when you know about it, but it might be worthwhile specifically pointing it out. Specifically ways to avoid trying to do a gluProject/unProject in a mouse click event.

Definitely mention the composable pipeline.

Also, provide a textured spinning cube so that they can start playing with it.

Even though this is not jogl specific, I think It would be good to give some sort of warning about being careful with state manipulations since they carry over.

JInput on one hand as it is the preferred method for dealing with input devices, but in general you have to deal with input devices differently with JOGL than you do with a regular C application with event handler semantics and so forth.

There is also the annoyance with swap buffers though it looks as though that may go away in the near term.

[quote]So I’m very curious, what examples/projects have other people bumped into this problem on, because we weren’t planning on same much beyond, “Must access JOGL operations on the same thread” or the more eloquent “JOGL isn’t thread-safe like many Collections”
[/quote]
My guess - most people start by drawing a coloured quad, then work out why it doesn’t appear (winding order), then blend different colours across it, then learn about glEnable and glDisable. At that point they try to make some state switchable via a keypress, and things go horribly wrong.

If they get past this point, they’ll never have any problems with it again, but I think this is usually where the problem crops up. It’s not something that turns up in a production system, but will often be hit in small test programs - the obvious way to switch a state at runtime is the way that won’t work.

The only issue we’ve really come across right now is the lack of buffer swap control and that the proposal for JOGL is going to be quite different to just a simple glSwapBuffer call. However, that’s a little more advanced than an intro chapter level.

[quote]The only issue we’ve really come across right now is the lack of buffer swap control and that the proposal for JOGL is going to be quite different to just a simple glSwapBuffer call. However, that’s a little more advanced than an intro chapter level.
[/quote]
I was going to mention that point too - infact there is a current thread on the Java3D-Interest mailing list titled “Volume”, with some complaints from Justin Couch that JOGL not having that method means that JOGL is not really a true OpenGL wrapper.

Will.

There’s nothing in the GL specification about buffer swapping. It’s a platform-dependent feature. An incredibly important and useful platform feature of course :wink:

Cas :slight_smile: