1
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 10, 2021, 10:22:44 am »Thank you EgonOlsen for you hints. I'll continue to dig into this issue...
News:
Recent Posts
2
Support / Re: JPCT and Jide Docking Framework
« Last post by EgonOlsen on September 09, 2021, 11:05:23 am »Oh, and one other thing: You can (and should) remove this line from the Renderer class:
It's not needed here and will bite you once the window has the same dimensions as a valid fullscreen video mode by some coincidence.
Code: [Select]
_buffer.enableRenderer(IRenderer.RENDERER_OPENGL);
It's not needed here and will bite you once the window has the same dimensions as a valid fullscreen video mode by some coincidence.
3
Support / Re: JPCT and Jide Docking Framework
« Last post by EgonOlsen on September 09, 2021, 11:02:51 am »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.
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.
4
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 09, 2021, 10:43:41 am »Ic. Hopefully reseting renderer will fix the issue at the end. Could you share the way you managed to have the box visible in white? That might give a hint for more possible solutions.
Another question...
I applied the solution to main project, but it fails with many NPEs inside of JPCT:
Maybe you have a quick hint why is happening so?
Another question...
I applied the solution to main project, but it fails with many NPEs inside of JPCT:
Code: [Select]
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: java.lang.NullPointerException
at com.threed.jpct.AWTJPCTCanvas.paintGL(AWTJPCTCanvas.java:238)
at org.lwjgl.opengl.AWTGLCanvas.paint(AWTGLCanvas.java:339)
at org.lwjgl.opengl.AWTGLCanvas.update(AWTGLCanvas.java:368)
at java.desktop/sun.awt.RepaintArea.updateComponent(RepaintArea.java:255)
at java.desktop/sun.awt.RepaintArea.paint(RepaintArea.java:232)
at java.desktop/sun.awt.windows.WComponentPeer.handleEvent(WComponentPeer.java:358)
at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5073)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4844)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.NullPointerException
at org.lwjgl.BufferChecks.checkDirect(BufferChecks.java:126)
at org.lwjgl.opengl.GL11.glDrawElements(GL11.java:1101)
at com.threed.jpct.CompiledInstance.render(CompiledInstance.java:732)
at com.threed.jpct.AWTGLRenderer.drawVertexArray(AWTGLRenderer.java:1349)
at com.threed.jpct.AWTJPCTCanvas.paintGL(AWTJPCTCanvas.java:198)
... 24 more
Maybe you have a quick hint why is happening so?
5
Support / Re: JPCT and Jide Docking Framework
« Last post by EgonOlsen on September 08, 2021, 01:54:53 pm »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.
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.
6
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 08, 2021, 10:37:00 am »Sent the project link to you in a private message. The forum reported it as "successful" even I can't see the message in the list of Messages. Hopefully you got it
7
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 08, 2021, 10:24:16 am »Disposing the buffer and recreate again when frame moved seems to do the trick. The cube is shown again . I'll apply the hack to main project to see how it works. The link to project I'll send you in a private message 
. I'll apply the hack to main project to see how it works. The link to project I'll send you in a private message 8
Support / Re: JPCT and Jide Docking Framework
« Last post by EgonOlsen on September 07, 2021, 08:15:38 pm »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...
9
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 07, 2021, 05:18:12 pm »Jide has listeners for frame's different states... as a possible solution I was thinking about "reseting" the renderer when frame in moving around. So the next question is how to "quickly" (without reloading textures and other time consuming tasks) reset/recreate/reinit the renderer in the correct way? (If that is possible)
10
Support / Re: JPCT and Jide Docking Framework
« Last post by kavyro on September 06, 2021, 08:36:04 pm »Thank you EgonOlsen for your effort. Your help is really appreciated
To exclude differences between batched/not batched elements I created a small new "fresh" project with the code form https://www.jpct.net/wiki/index.php?title=Using_jPCT_in_Swing and Jide. The code was adapted to initialize and run in same way as main project:
- jpct (rendering) stuff like "game" loop is running in main thread,
- UI stuff is running in EDT,
- jpct renderer and UI communicate through listeners when it is needed.
As a result I got same issue - the 3D cube is running OK until the frame is moving around and "disappears" afterwards.
I can send you the project code anytime if you want to have a closer look to it.
To exclude differences between batched/not batched elements I created a small new "fresh" project with the code form https://www.jpct.net/wiki/index.php?title=Using_jPCT_in_Swing and Jide. The code was adapted to initialize and run in same way as main project:
- jpct (rendering) stuff like "game" loop is running in main thread,
- UI stuff is running in EDT,
- jpct renderer and UI communicate through listeners when it is needed.
As a result I got same issue - the 3D cube is running OK until the frame is moving around and "disappears" afterwards.
I can send you the project code anytime if you want to have a closer look to it.