Posted by Marian Schedenig on Aug 25, 2014; 9:55pm
URL: https://forum.jogamp.org/Where-when-is-it-ok-to-call-setFullscreen-tp4032828p4032930.html

Ok, I solved it. I failed to reproduce it in a test case, unfortunately, but trying to port over bits and pieces at least showed me roughly where the crash originated. I'm still not exactly sure what causes it, I can just describe the general situation.

I have several listeners on my GLWindow. The input listeners for the keyboard and mouse just translate input events to internal data structures and add them to an input queue. Then during my main loop, which is triggered once per frame by the display() callback method, I do the following:

1) Clear the screen via glClear().
2) Iterate through the queued input events.
3) Update my game logic (fixed rate loop).
4) Render a frame.
5) Return whether to keep running or quit the application.

Then back in display(), if the main loop returned false, I stop the animator and quit.

I have a custom set of GUI classes for drawing windows, labels, buttons etc. and handle input events for them. These are all processed during step 1. Fullscreen mode is toggled via a button that can be clicked (mouse down inside the button, followed by a mouse up inside the same button) or focused and triggered with the Enter key (keyDown event - keyUp is handled as well, but not used to trigger the button).

I was certain that both a mouse click and an Enter press trigged the crash, but it turned out that everything worked fine when I used only the mouse. Either I was mistaken, or during my first tests there were still more problems that also caused crashes with the mouse, and I'd "accidentally" fixed them while trying to figure out the problem. In any case, only the keyboard was causing the crashes. The button called a setFullscreen() method in my window wrapper class. Directly checking for the "f" key in the window listener's keyDown callback and calling setFullscreen() from there instead of queuing the key press also worked just fine.

So I removed the direct call to setFullscreen() from my button click callback. Instead, I now set a flag on my window class, and after calling the main loop, I check that flag in display() (let's call that step 6) and call that same setFullscreen() method if the flag is set. And it's solid as a rock this way.

The odd thing about it is that the mouse click and key presses trigger the same callback method. And it's all happening in step 2. There should be no drawing code whatsoever outside step 4, except for step 1. So both the input events and the drawing are completely decoupled from the part where I used to trigger setFullscreen(). And even if I move step 6 between steps 1 and 2, it runs just fine.

I expect it must be something very specific to my code (there's probably a stray call to some minor graphics update somewhere in my game logic that I haven't been able to find) and won't be of much help to anyone, but this is what I've been able to boil it down to, for what it's worth.