The white box appeared after setting Config.glUseVBO and Config.glVertexArrays both to false. But that's not a good option, because it hinders performance and doesn't really help anyway.

About the exception: Actually, that's a NP in LWJGL, not in jPCT. I think it's a race condition when the AWT thread is still paiting while you switch the buffer in some other thread. This might cause LWJGL to lose the context und crash.

You somehow have to make sure that no painting happens when switching or switch in the AWT thread (an IPaintListener can help with that)...but I'm not sure that the latter is a good idea though.

Yes, I did. I played around with it, but I can't see anything wrong in the way in which jPCT handles this. I think that this is either an issue with LWJGL's AWTGLCanvas or Jide is doing some hacky things to work its magic that interfere with what LWJGL expects from AWT/Swing.

I managed to configure jPCT in a way that at least the box shows up, but the colors were all white after an undock. I think what happens here, is that the GL context that is bound to the AWTGLCanvas by some magic is lost when Jide undocks the canvas. When talking to an invalid context, it often happens that some things still work while others fail. This is more a driver bug than a feature, because actually, rendering into an invalid context should give you no rendering at all.

If that's the issue, I think that recreating the FrameBuffer actually is the correct solution here.

You can try to call dispose on the renderer and create a new one. I'm not sure how the underlying AWTGL implementation handles this though, but it's worth a try. Feel free to send me your test as well, so that I can see for myself and at least admire the problem...

Another difference is, that you compile the non-batched objects as dynamic, but not the batched ones. Have you tried to use the exact same compile-call for the batched ones as for the non-batched ones?

Strange. Actually, it might be a better idea to do the resize in the main thread, not in the event thread in which the listener is being called, because it pushes a new command into the pipeline that is actually being executed at that stage. But I doubt that this will fix the issue. It's worth a try though.

I've splitted the topic, because it doesn't really belong into the cCPT thread.

You are right. Java lost a bit of momentum over the years regarding game development, at least on the desktop. It's still strong on Android either directly or in combination with Kotlin. But even there, things like Unity or Unreal Engine are way more popular. That said, one of the most popular games of all time is still Java based: Minecraft.

Try to replace the Object3D.compileAndStrip() call with Object3D.compile(). If you strip them, some data needed to upload it again to changed GL context might get deleted. A resize will most likely change the context, so maybe that's the issue.

Where are you doing the resize? Directly in the component listener?

Is there any other log output from jPCT when the resize happens?

I'm not sure, what you mean. jPCT is free, but not open source. AGP started the C# port based on the jPCT sources, which he has because he paid for them. What you do want to 'contribute'?

jPCT actually doesn't really care to where it outputs the rendering, at least not in a way that it should matter in this case. Are you calling FrameBuffer.resize() when the size of the output window changes?

That actually doesn't look wrong to me at first glance. Does any object has a listID other than 0? If not, it might help to check where it gets assigned.

Or the rendering itself is faulty. Hard to tell. You can get the returned center of the objects. If that lies within reasonable bounds, the object should be visible. I think there is also a method similar to wasVisibleInLastFrame() or something like this in Object3D that you can call to see if the object was, well, visible (geometry wise, it doesn't mean that it has been rendered).

C# compiles into CIL, which is bytecode as well. It's very similar to what Java does, hence the similar performance characteristics. It should be possible for it to print out a line number. With this error message alone, it's almost impossible to find out, what is null here. Maybe you can configure the compiler to include line numbers? Some debug mode or similar?

No line number of any kind?