Is it possible with JOGL to change the OpenGL State outside of the display() method? I realize that I will need to refresh my GLCanvas for display() to be called in order for the GLCanvas to display the changes, but, for example, in gl4java you couldn’t make any OpenGL calls outside of the display() method at all.
I would like to be able to call methods that change the OpenGl state and just refresh the GLCanvas.
Thanks.
Gregg
Same for me.
I want to generate textures between init() and display().
Hi
As i’ve learned in this forum, i will answer no to your question. You need to have a valid drawable to do OpenGl calls and the only way to do that is to be in the display method (or the reshape or init).
I think you can also set the rendering thread for the GLCanvas but it may raised more problems than it solves.
That is correct. The only time that you can actually draw in JOGL is when the drawable is valid - and that’s only in a small window during the display. Outside of that your calls will go to the JOGL equivalent of /dev/null.
Then it would be at least nice to get a JOGLDevNullException …
And how about scheduling a Runnable-like for later execution?
It is getting late…
You can not reflect the changes instantly, well I assume you make changes through mouse events, since event thread is running before that of rendering when triggered by glcanvas repaint. It seems Jogl is not safe, when it deals with events especially when rendering big volumes of objects.
No. As I have written in another post I want to generate textures.
This is my current problem with JOGL:
I have a bunch of images which i want to convert to textures. My current solution is to preload the images and put them in a list for later handling. This list is worked through when init() is called which happens only one time when the frame which belongs to my GLCanvas is made visible.
Whenever I need another texture and the game is running already (e.g. entering next level) I have to generate the texture from the display() method. But this takes some time and while doing the conversion the gui is freezed.
Is there no other possibility to handle texture generation?
Just realized that texture generation from init() is freezing the gui as well. So there is REALLY no way to do texture generation and show a JProgressBar ?!?
I don’t know how professional games handle time consuming operations, but I suspect that :
most of them are performed at level-loading time (where there is almost no GUI response, even progress bars don’t progress “smoothly”),
if it has to happen during game, it is broken down into smaller parts so that it may span over several frames.
Texture generation can usually benefit from the latter.
[quote]No. As I have written in another post I want to generate textures.
This is my current problem with JOGL:
I have a bunch of images which i want to convert to textures. My current solution is to preload the images and put them in a list for later handling. This list is worked through when init() is called which happens only one time when the frame which belongs to my GLCanvas is made visible.
Whenever I need another texture and the game is running already (e.g. entering next level) I have to generate the texture from the display() method. But this takes some time and while doing the conversion the gui is freezed.
Is there no other possibility to handle texture generation?
Just realized that texture generation from init() is freezing the gui as well. So there is REALLY no way to do texture generation and show a JProgressBar ?!?
[/quote]
do all of your texture loading befor hand (or he majority) you can bring some new textures every frame. Or have images loaed in a separate thread and just have the GL thread send data to the GL.
i.e.
loading thread:
running()
{
while ()
{
if (ImageLoadQueue.hasMoreElements())
{
image = ImageLoadQueue.removeFront();
image.loadfromFile();
//tell the gl thread the image is loaded
sendTextureLoadedMessage(image);
}
}
}
openglThread()
{
while (texturesToLoad) { //get message from other thread with data to send to gl
glTexImage2D(…, nextTexture);
}
}
maybe each frame you cap the max textures that can be sent to GL. so it wont hang on one frame too much. Also remember to make sure things are all synced up when your using multiple threads.
Additionally you could use some of the texture compression extesnsions so your loading and sending less data.
Thanks overnhet & wes,
your posts gave me a good idea of how to I can optimize the texture generation.
–
damn this was so easy. I solved the whole issue the following way:
using list to generate most of the texture from init() and later loaded ones in display()
cut the texture loading code in a Java part and a JOGL part.
Java part: time consuming but not freezing the gui 
JOGL part: not so slow anymore because the needed (direct) ByteBuffer(s) are already set up and only made available to JOGL.
win1: I can now inform the user about the progress of the texture preparation …
win2: Recreation of the textures after a fullscreen/windowed mode switch can be implemented now without the fear of freezing the gui forever 
thanks again
How about disposing of textures? When a glCanvas goes away, does all of the textures that you loaded using that gl context also go away?