LwjglCanvas backend improvement (LWJGLX + AWT)

[JNightRider]

I have recently been working on the problem that LwjglCanvas is currently presenting:

• Remove and add the canvas
• The poor performance it has (low fps)

These errors have now been corrected; the problem when deleting the canvas was that the renderer was not invalidated when creating the new one.

The performance problem was due to the thread remaining idle for 10 milliseconds and glwf creating a context, which meant that two contexts were running.

Screenshots

Some screenshots, whether running natively or with AWT, show that JME3 looks exactly the same (the window on the left is from the native version, the one on the right is from the AWT version).

Linux (Wayland + XWayland)

Windows

While removing and re-adding the canvas works perfectly, using a LightProbe generated by FastLightProbeFactory.makeProbe(...) can cause program crashes, and the new shadow filter SdsmDirectionalLightShadowFilter might not work (when removing and re-adding the canvas). These filters must be removed before deleting the canvas from its main components and then re-adding it when inserting it.

It is not currently compatible with OpenCL(), as the lwjgl3 module is tightly linked to glwf.

[gemini-code-assist]

Code Review

This pull request refactors the LwjglCanvas implementation to improve OpenGL context management and lifecycle handling within AWT/Swing environments. Key changes include a new main loop in the run() method, the introduction of explicit lock/unlock and context creation methods, and logic to handle Wayland/X11 platform detection. Several methods and fields in LwjglWindow were changed to protected to facilitate this. The review feedback identifies several critical issues: the renderable flag is never reset after context recreation, which would stop the display; blocking the AWT Event Dispatch Thread (EDT) with lock.wait() poses a high risk of deadlock; and skipping the superclass call in createContext() bypasses glfwInit(), potentially breaking GLFW-dependent functionality. Other feedback points out potential NullPointerExceptions, redundant flag assignments, missing GLFW event polling, and the use of System.out.println instead of a logger.

[gemini-code-assist]

Blocking the AWT Event Dispatch Thread (EDT) with lock.wait() is risky. If the render thread (which calls lock.notifyAll() at line 515) gets blocked by any operation that requires the EDT (e.g., a synchronous AWT call within listener.loseFocus() or renderer.cleanup()), a deadlock will occur, freezing the entire application UI. Consider using a timeout or an asynchronous signaling mechanism to avoid blocking the EDT indefinitely.

[gemini-code-assist]

This assignment is redundant. The reinitcontext flag is already set to false by the render thread using getAndSet(false) at line 503 before it notifies this thread.

[riccardobl]

Thanks! Feel free to go through gemini's suggestions or to close them if they are wrong.
Just one note: don't worry too much about opencl, we are likely going to drop it anyway at some point.