The wierd thing is that after having done one toggle the ORTHO que is drawn with highest ZOrder infront.
Javadoc for dispose():
Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.
One thing I need to do after a dispose is reset the camera other than that everything seems to work. My question is how the ZOrder can flip after a dispose()? I have tried to look thru the source if there is anything that can affect this but without luck.
This is driving me crazy. Here is a simple runnable program so you can see what I mean.
We have a red square B(ZOrder=-10) getting drawn in front of a blue square A(ZOrder=0). One screen toggle and the drawing order is inverted.
From what I can see during a debug there is no difference in what is done. The orthoBucket is sorted the same the drawing order is done in the same order both before and after a dispose(). But visualy on the screen is clear they aren't ordered in the same way. Don't know how lwjgl works tho if there is some lowlevel GL that can affect the order that is not related to the order in which you call lwjgl's draw methods.
Displaying a frame that was disposed is a bug. If you call dispose() method on your frame, you have to reinitialize the frame from scratch to make sure all of the frame's subcomponents are in working condition.
What happens is your glCanvas is being disposed because it's a subcomponent in the frame. However the glCanvas is never reinitialized. So what you are seeing is a disposed version of glCanvas ready to be destroyed. The fact that anything at all is being displayed is a mere coincidence.
I think adding ortho nodes to a non-ortho node is generally a bad idea.
As i understand it, the ortho rendermode should be set at the root Level.
Yeah your right. But it doesn't seem to matter. I have the scene nodes and my ORTHO node separated and do separate render.draw() on them. I still get the ZOrder flip when I have a ZBuffer in my scene. :x
Displaying a frame that was disposed is a bug. If you call dispose() method on your frame, you have to reinitialize the frame from scratch to make sure all of the frame's subcomponents are in working condition.
The javadoc for dispose() says:
Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.
The Window and its subcomponents can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its subcomponents will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).
so doing a
dispose()
.
.
setVisual(true);
is what is the online examples say you should do when switching between windowed and fullscreen mode.
What I do in my application after this is reinit the renderer and camera. Everything works just fine except that the ZOrder flip. That seem to be caused by the ZBufferState in my scene having been reset by the dispose().
I guess the only reliable solution to doing a dispose() is to save the scene and reloading it since the ZBufferState for example seems to be replace by a completely new and reset object and maby that will happen to other other states aswell?
With my current test. reinit of the Renderer, the Camera and the ZBufferState is enough. But since I don't really understand exactly what happens when dispose is called.. it don't seem safe :X
You are right… I did some testing, and dispose() is not the what's cause the problem. Try calling toggleFullscreen() a couple of time in init() method.
The ZBufferObject is the same one as well…
The problem seems to occur only when calling dispose() from awt event dispatch thread. Synchronizing repaint on an external variable doesn't work either. Very very strange.
Try calling toggleFullscreen() a couple of time in init() method.
actually. When you call setVisual(true) for the first time in the init, it will take a little bit before the first paint is issued by the system. This paint will make the glCanvas call setup on its implementation. Setting up the camera, ZBuffer and stuff.
So your toggleFullscreen() in the init() was probably done before the camera and ZBuffer was created. If you do a Thread.sleep(1000); right after setVisual(true) in the init and then do toggleFullscreen(). The effect will be the same as when running from the awt event thread. So the dispose() is the culprit. Would just be interesting to figure out exactly what effect it has, if it is enough just to reinit the renderer, camera and ZBuffer.