Do you really have to call it in every different method that needs to call a gl function? If so, is that a performance problem?
If not, what's the strategy for storing the context so all the different methods can call it?
Strategy is to store the GLContext/GLDrawable (low level)
or the higher level GLAutoDrawable (combined GLContext)
at your code level where you construct your resources (surface/window, etc).
Then, if using the higher level API, you implement GLEventListener
and add them to your GLAutoDrawable.
The GLEventListener methods are then called by the GLAutoDrawable,
passing the GL instance to you, which reference the current GLContext.
The GLAutoDrawable takes care of making the context current and all that.
Browse through our unit tests and demos to get familiar with it perhaps.
On the low level side w/o GLAutoDrawable, you have to create and make your GLContext
current and of course need to somehow manage it.
GLContext.getCurrent() returns the Thread-Local-Storage (TLS) GLContext. instance
managed internally and therefor is not really a big burden - even though
using the GLAutoDrawable + GLEventListener model is easier and more clear.
GLContext.getCurrentGL() uses GLContext.getCurrent() and returns its GL reference.
I have three choices:
- on display() store the context in a global (poor design)
- on display() call all my other methods and have them call GLContext.getCurrentGL(). (basically the same thing)
- on display() call all my other methods and pass them the gl context. (more stack work)
Why not pushing GLRunnable instances like in JogAmp's Ardor3D Continuation?
You can call GLAutoDrawable.invoke(boolean wait, GLRunnable glRunnable) or add GLEventListener instances into the drawable queue by calling GLAutoDrawable.addGLEventListener(GLEventListener listener). My suggestions allow to handle many different use cases, both for regular and non regular access to OpenGL.
Please don't take the risk of using invalidated GL instances, the high level API is a lot less error prone. Storing a GL instance into a global field is a very bad idea.
P.S: If I were you, I would use GL instances only locally, I would store it only into local variables. When you use JOGL, you end up with writing your own scenegraph API somehow when you don't already use the scenegraph API created by someone else, some part of your own source code has to be aware of manipulating OpenGL. When the separation between the OpenGL-aware source code and the rest of the source code is clear, you're on the right road even though you decide to pass GL instances to methods which is more risky.
in trying to implement my scene switching functionality, i've discovered i can't switch scenes, because when i try to call getCurrentGL(), i get a "no opengl context for current thread" error...i'm new to this, and still trying to get a grip of how to deal with the context...
i sorta follow along with some of the things you said, but if i could see it implemented that would help...
it says theres no context for the thread. i'd really love to fix this problem so i can move on, and more than that, know how to properly deal with the context for my whole app because i think im doing it wrong where every method that needs a gl function has to get a context first, it doesn't right...thanks for any help
I expected a link to a GIT repository, Google Drive isn't appropriate to share source code.
You should have read my comments more carefully. Storing a GL instance into a non local variable is typically a bad idea. You cannot force OpenGL to work like you would like, the OpenGL context is not current when you try to manipulate it.
The source code that needs to manipulate the GL instance should be only in the GLEventListener implementation.