Hi, I don’t know if this is the correct category for this topic… I just submitted a PR that integrates lwjgl-jawt to finally use the LwjglCanvas class
[ Screenshots ]
There is just one small detail, removing the canvas from its main component and integrating it again breaks it. This issue occurs on the lwjgl3-awt side (LWJGLX/lwjgl3-awt#40)
Thank you! Do you happen to know does it function in MacOS?
extends LwjglContext ,LwjglWindow , Which one is better? LwjglWindow Mainly to initialize glfw window.
In theory it should work, the lwjgl3-awt documentation itself says so, unfortunately I don’t have a computer with MacOS to check it
If anyone is willing to do testing (MacOS), it would be a great help.
@donting it all depends on what you want to do
In the case of LwjglCanvas it is better to inherit from the LwjglWindow class to facilitate its maintenance, and it was not necessary to inherit from LwjglContext since it does not need it
This is great and addresses the major issue I have with JMonkeyEngine (swing not working with current version of lwjgl3).
I tried using your PR with my application. The good thing is it works.
Sad news for me is that the frame rate was much lower.
For me, this is still an improvement, as I can run in a configuration that did not work at all before. However it would be good if the frame rate was not impacted so severely.
This is the log if that helps. Running on windows 10
INFO: Running on jMonkeyEngine 3.7.0-SNAPSHOT
* Branch: LwjglCanvas_lwjgl-jawt
* Git Hash: 732f92a
* Build Date: 2024-01-22
Jan 22, 2024 12:19:40 PM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.3.3+5 context running on thread jME3 Main
* Graphics Adapter: GLFW 3.4.0 Win32 WGL Null EGL OSMesa VisualC DLL
Jan 22, 2024 12:19:40 PM com.jme3.system.lwjgl.LwjglCanvas printContextInitInfo
INFO: Initializing LWJGL3-AWT with jMonkeyEngine
* Double Buffer: true
* Stereo: false
* Red Size: 8
* Rreen Size: 8
* Blue Size: 8
* Alpha Size: 0
* Depth Size: 24
* Stencil Size: 0
* Accum Red Size: 0
* Accum Green Size: 0
* Accum Blue Size: 0
* Accum Alpha Size: 0
* Sample Buffers: 0
* Share Context: null
* Major Version: 3
* Minor Version: 2
* Forward Compatible: false
* Profile: COMPATIBILITY
* API: GL
* Debug: false
* Swap Interval: 1
* SRGB (Gamma Correction): false
* Pixel Format Float: false
* Context Release Behavior: null
* Color Samples NV: 0
* Swap Group NV: 0
* Swap Barrier NV: 0
* Robustness: false
* Lose Context On Reset: false
* Context Reset Isolation: false
Jan 22, 2024 12:19:40 PM com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFO: OpenGL Renderer Information
* Vendor: ATI Technologies Inc.
* Renderer: Radeon RX 570 Series
* OpenGL Version: 3.2.14802 Core Profile Forward-Compatible Context 21.12.1 30.0.14011.3017
* GLSL Version: 4.60
* Profile: Core
Hi @awmross
Thank you very much for taking the test, it is very important to confirm that it works correctly (especially on Windows, which is very ‘capricious’) 
.
Thanks for letting me know, this unpleasant performance is because the buffer swap was done twice; one by GLFW and the other by lwjgl-awt (solved).
[ NOTE ]
I still have to publish several ‘commits’, related to this PR.
FYI I tested 3.7.0-alpha3 and saw the same performance issue with lwjgl3 vs lwjgl when running in a swing window as I reported previously. I saw there were some extra commits since my initial report but they don’t seem to have fixed the issue I am seeing.
It’s strange that this keeps happening.
You should keep in mind that, to run AWT with lwjgl3; first the awt thread is loccked so that lwjgl3 can draw, then it is unlocked to give control to AWT; This can have high costs if the scene to be rendered is not optimized.
View 1
I can get stable 80-90 fps on a mid range laptop.
View 2
adding post-processing and a parallel physics engine (dyn4j, which is quite demanding), I get 60-80 fps
[ NOTE ]
All these tests were done on Linux (Debian 12) with Wayland window system (surprisingly, it worked not only on X11 also on this window system).
[ EDIT ]
All of these tests use only the GPU; with a graphics component (nvidia RTX…) it should offer more fps.
mar. 13, 2024 7:19:23 P. M. com.jme3.system.JmeDesktopSystem initialize
INFORMACIÓN: Running on jMonkeyEngine 3.7.0-alpha3
* Branch: HEAD
...
mar. 13, 2024 7:19:24 P. M. com.jme3.renderer.opengl.GLRenderer loadCapabilitiesCommon
INFORMACIÓN: OpenGL Renderer Information
* Vendor: Intel
* Renderer: Mesa Intel(R) UHD Graphics (CML GT2)
* OpenGL Version: 4.6 (Core Profile) Mesa 22.3.6
* GLSL Version: 4.60
* Profile: Core
It looks like it is running on the internal intel graphics card. Or am I missing something?
Hi @ndebruyn
Exactly, everything is in the internal GPU.
By optimize, do you mean use GeometryBatchFactory.optimize ?
I am using Blocks framework (there is a thread on this forum for it). Similar to Minecraft. I am not sure if it is Optimized.
Not necessarily, for example, a model with 10000 vertices is not the same as one with 100000 (if the model is quite simple); as well as loading many objects at the same point (condensation)
Blocks uses jme3 version 3.4.x; Isn’t this an important factor in performance? (Correct me if I’m wrong)
I don’t think Blocks is tied to any particular version of jme3. I am testing against 3.7.0-alpha3.