drawing outside of display()

OpenGL Development JOGL Development
#1

I have been using gl4java for a while and while it is desent, there are some major drawbacks to this OpenGL Bind. Which is why I am taking a look at JOGL.

One of the problems I have with gl4java is that it does not allow you to modify or manipulte the canvas outside of the display() method. ALL drawing has to be done in this method alone.

Is this the same in JOGL? Because when developing in C/C++ with OpenGL this is not a problem and makes life a lot easier.

Thanks.

Gregg

#2

No, it is not required. It’s only required if you’re going to use the default Animator class. But I think you still need a central point from which to start your renderer. Each of your objects can have a draw() interface or whatever you wish to call it. But only one thread at a time can access the rendering context. It’s best to leave all drawing within one thread. In the long run, I’ve found I might as well just use the Animator callback to display() and start my rendering process there. I can then iterate over a list of Drawables, separating the drawing functions out to different classes.

I read a good Microsoft article years ago when I was first learning OpenGL. Doing a quick search, I found this link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/ntopnglo_9zjn.asp

#3

Thanks for the quick response.

So as long as I get the GLContext or GLDrawable rather, then I can manipulate the canvas from anywhere?

So do I still have to CALL the display() method for it to update?

The thing with OpenGL in C is that you don’t have to call paint() repaint() display() bla bla. If you draw something, it gets drawn. OpenGL actually handles that. But I know in JAVA since you are dealing with an object oustide of OpenGL (a panel or some sort) once OpenGL makes it’s updates, the JAVA part has to be updated as well.

So instead of letting OpenGL call it’s own update, you have to call display() or something.

Does this make sense?

#4

You probably should read over this thread: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1063385846

In OpenGL and C, you still need to have some sort of SwapBuffer call. OO coding is not the same as procedural coding. You aren’t forced to have threads in C or C++, but you almost can’t avoid them in Java.

Case in point, I got bit by this one: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1062732993;start=0#0

#5

Your problem is the exact problem that I am getting ready to deal with.

Even if the performance hit is minimal, who wants one display() method that contains ALL your drawing code. That is rediculous. Especially with an OO language like JAVA. Things need to be kept more modular.

So is the SwapBuffer methods going to solve this issue?

#6

I just found out also from that other thread that the makeCurrent() method is hidden from developers to make rendering play nice with AWT and SWING.

What crap!!

So, yet again, another decent attempt to port the OpenGL API to JAVA might fail.

Other than SGI being involved, what’s the big deal with JOGL then?

Very disappointing indeed…

Gregg

#7

My solution is little different than what I did under C++. My display method is pretty small. Here’s an example:


void display(GLDrawable glDrawable)
{
  final GL gl = glDrawable.getGL();
  Iterator i = drawableList.iterator();
  while (i.hasNext())
  {
    Drawable drawable = (Drawable)i.next();
    drawable.draw();
  }
}

Forgive any glaring errors, I typed that in by hand to simplify the example.

#8

So you have a seperate draw() method for each of your objects, as you stated earlier. And then the main display() iterates through all those objects and calls their draw() method.

Pretty slick approach. Notice any performance hits?

#9

Naaa, a number of extra method calls won’t make any hit at all; nor even the new Iterator being created each frame. You’ll have much larger bottlenecks elsewhere.

#10

Well, what about this.

Say you have 1000 objects. And only 2 of those are actually updating the OpenGL State.

Does it matter that you are iterating through 998 objects that haven’t changed?

#11

I honestly can’t tell you about how framerates are affected. My app isn’t complicated enough yet. But my thoughts are if you’re concerned about function calls slowing you down, then Java isn’t a good choice. As cfmdobbie said, there are a lot of other things to worry about besides method calls.

You still have to draw the 1000 objects each frame. Not every object should be altering states. If objects 25 and 27 in the list are lit with OpenGL lighting but object 26 is should have lighting turned off, then 26 should toggle the state and restore it at the end of its draw method. Keeping track of all this can be a royal pain. That’s the main reason I like the scene graph concept.