Hi,
When I set Debugger,
“canvas.setGL(new DebugGL(canvas.getGL()));”,
I get “java.lang.OutOfMemoryError” and program crashes.
Any idea, why??
Thanks…
Hi,
When I set Debugger,
“canvas.setGL(new DebugGL(canvas.getGL()));”,
I get “java.lang.OutOfMemoryError” and program crashes.
Any idea, why??
Thanks…
I usually get an Out of Memory error when I try to do something when the context isn’t set up right.
If you use the debug version, it will test the state of the OpenGL error after every operation. But the glGetError() itself seems to be an error at some points. The method that checks this calls glGetError() repeatedly, until the error clears, and appends the errors in a string buffer. If the glGetError() itself returns an error, it’ll never clear, and the buffer just expands until memory is used up.
It seems to me that some limit on calls to glGetError() would be appropriate. If that limit is hit, seems an error message about that would be helpful.
So look to make sure that all your OpenGL calls are only done inside GLEventListener.init() and .display() methods, when all is ready.
andy
Thanks, Andy.
It seems, calling opengl from events is a big “no”.
That is right, instead of playing with debugger in and out, the best is to go the way without making any call from events.
OpenGL is not thread safe, and so you can only make GL calls within the same thread that does the drawing. AWT events come in from a different thread so you can’t touch OpenGL state at all from them.
I should add this to the wiki…
I have not tried this, so I could be wrong, but if you create your canvas and then set the rendering thread to the AWTEvent thread then you would be able to make “naked” opengl calls without worrying about the context being current on that thread. If I get a little time tonight I might see if this works, though I can think of a number of reasons not to do this. Please read this article, it may be very helpful in understanding JOGL.
Thanks for the hints.
User Guide is no doubt great help, I thing some details must be emphasised with more plain English.
It seems the more plausible way is to get the threads syncronized between rendering and awt events. Please let me know I you get it works.
An other issue,
int[] pickBuff = new int[count];
gl.glSelectBuffer(count, pickBuff );
I get nonzero hits, but pickBuff is emty some times, one out of ten presses.
I thing mouse release thread is a little bit late.
Any idea??
Thanks.
My idea about setting the redering thread to be the AWTEvent thread does work. The down side is that the FPS of the test app I used was less than half of the FPS if I use the Animator class. Another down side is that if you do all your rendering on the event thread you will be slowing the gui response to all the other gui events. Basically all you have to do is call canvas.setRenderingThread inside a runnable on the event thread using one of SwingUtilities invoke methods. You will still have to call display to get the buffers to swap. If you want it animated then you will have to use the swing Timer class and put the display call in the actionPerformed method.
Thanks,
I need to experiment some…