{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih6r3ucqmq4b5ayss32pkoriiac4qbj6auukw6v2zksqtmlh642za",
    "uri": "at://did:plc:dxjzgxe7cvirxkwfjr2tjspt/app.bsky.feed.post/3mnvlutxvhzi2"
  },
  "path": "/t/vlog-03-integrating-dear-imgui-1-92-0-with-latest-jme3-initial-findings-traps-and-architecture-choices/49616#post_1",
  "publishedAt": "2026-06-09T21:30:23.000Z",
  "site": "https://hub.jmonkeyengine.org",
  "textContent": "Hi everyone,\n\nI am currently running some integration tests between the latest versions of the **`imgui-java`** wrapper (specifically targeting Dear ImGui 1.92.0+) and **jMonkeyEngine 3.10.0+**.\n\nMy goal is to build a robust, desktop-targeted UI integration layer. During my initial research and implementation phases, I encountered a few architectural shifts in both ecosystems that drastically change how we used to integrate ImGui in the past.\n\nI wanted to share my current findings with the community as a personal study. _Please note: these notes represent the current state of my ongoing tests. Some assumptions might be partial or subject to change as I dive deeper into the engine’s source code, so feedback or corrections from anyone more experienced are highly welcome!_\n\nHere is a summary of the pros, cons, and structural gotchas that have emerged from my test environment so far.\n\n* * *\n\n### 1. The jME Backend Shift: GLFW vs SDL3\n\nThe latest iterations of jME3 default to an SDL-based backend rather than the classic GLFW configuration.\n\n  * **Pros:** From what I can see, this is a great move for framework stability. SDL handles modern gamepads, complex multi-monitor environments, and Windows 11 DPI quirks much more robustly out of the box.\n  * **Cons (for ImGui):** This shift breaks immediate compatibility with standard ImGui setups. If you were relying on the well-tested `ImGuiImplGlfw` backend, you can no longer use it seamlessly if jME initializes the window context via SDL.\n\n\n\n### 2. The Multi-Viewport Dilemma in Java\n\n  * **Current Status:** In the `imgui-java` wrapper, the Multi-Viewport binding wrapper for SDL3 (`ImGuiImplSdl3`) does not seem to be fully completed or exposed yet, whereas it is fully operational in `ImGuiImplGlfw`.\n  * **The Catch:** * If you stick with **jME’s new SDL backend** , you might have to sacrifice Multi-Viewports for now, disabling `ImGuiConfigFlags.ViewportsEnable` and keeping all UI windows docked internally.\n\n\n\n### 3. Graphics API: OpenGL Desktop vs ANGLE (OpenGLES)\n\njME 3.10.0 introduces ANGLE as a default option (translating GLES3 commands into DirectX/Vulkan). On the other hand, the standard `ImGuiImplGl3` renderer bundled in `imgui-java` performs hard-coded queries to the desktop `org.lwjgl.opengl.GL` subsystem.\n\n  * **The Crash Trap:** If you boot jME with `AppSettings.ANGLE_GLES3`, `imgui-java` will crash instantly during `init()` with an LWJGL `IllegalStateException: setFunctionMissingAddresses has been called already`. This happens because LWJGL does not allow initializing both Desktop GL and OpenGLES capabilities simultaneously on the same thread context.\n  * **Current Workaround:** For a pure desktop target, forcing OpenGL Core Profile explicitly via **`AppSettings.LWJGL_OPENGL32`**.\n  * _(Note: Supporting ANGLE would technically require duplicating the ImGui renderer class and manually swapping all standard OpenGL static imports with`org.lwjgl.opengles.GLES30` counterparts, which might not be worth the overhead unless cross-platform mobile/web parity is required)._\n\n\n\n### 4. Mandatory Frame-by-Frame Sizing (`io.setDisplaySize`)\n\n  * **What changed:** In ImGui 1.92.0+, updating `io.setDisplaySize(logicalWidth, logicalHeight)` **on every single frame** inside your update/render loop is highly recommended, if not mandatory.\n  * **Why it matters:** With Windows 11 dynamic DPI scaling, moving a window across monitors with different scale factors instantly alters the logical bounds even if the pixel resolution looks identical. Updating this frame-by-frame prevents mouse misalignment and viewport stuttering.\n\n\n\n### 5. Input Sinking & Custom Adapters\n\nBecause of these backend shifts, relying on automatic platform callbacks from ImGui can cause conflicts. Writing a custom `JmeImGuiInputAdapter` (subclassing `RawInputListener`) seems to be the most reliable path.\n\n  * **Pros:** It allows for precise input consumption. You can check if ImGui wants the mouse/keyboard and call `evt.setConsumed()` to stop inputs from bleeding into your game’s camera or character controllers.\n  * **Cons:** It requires a fair amount of boilerplate code to manually map every jME `KeyInputEvent` or `MouseButtonEvent` to their corresponding `ImGuiKey` enums.\n\n\n\n* * *\n\n### Current Conclusion for my Setup\n\nBased on these early tests, if your target is strictly a **Desktop Tool/Game** :\n\n  1. Forcing jME to run on **OpenGL Desktop (`LWJGL_OPENGL33`)** feels like the safest choice to keep ImGui stable and performant.\n  2. If **docked (internal) UI windows** are enough for your project, sticking with jME’s new **SDL standard** is likely the best future-proof path. If you absolutely need **floating OS viewports** , falling back to the **GLFW** window context might be required until the Java SDL bindings mature.\n\n\n\nI am completely open to any thoughts, workarounds, or alternative viewpoints on this topic. If you have managed to get this combination working differently, or if any of my assumptions need a correction, please let me know!\n\n  * Dear ImGui (1.92.0+) with latest jME3\n\n\n\nNote: keep in mind that the latest versions of `imgui-java` now strictly require **Java 17** to compile the project\n\n\n    plugins {\n        id 'java'\n        id 'application'\n    }\n\n    group = 'com.jme3.imgui'\n    version = '1.0.0-SNAPSHOT'\n\n    java {\n        toolchain {\n            languageVersion = JavaLanguageVersion.of(17)\n        }\n    }\n\n    ext {\n    //    jmeVersion = '3.9.0-stable'\n        jmeVersion = '3.10.0-beta1'\n        imguiVersion = '1.92.0'\n    }\n\n    repositories {\n        mavenCentral()\n    }\n\n    dependencies {\n        // jMonkeyEngine\n        implementation \"org.jmonkeyengine:jme3-core:${jmeVersion}\"\n        implementation \"org.jmonkeyengine:jme3-desktop:${jmeVersion}\"\n        implementation \"org.jmonkeyengine:jme3-lwjgl3:${jmeVersion}\"\n        runtimeOnly \"org.jmonkeyengine:jme3-awt-dialogs:${jmeVersion}\"\n\n        // ImGui Java\n        implementation \"io.github.spair:imgui-java-app:${imguiVersion}\"\n        implementation \"io.github.spair:imgui-java-binding:${imguiVersion}\"\n\n        // Native libraries (multi-platform)\n        runtimeOnly \"io.github.spair:imgui-java-natives-windows:${imguiVersion}\"\n        runtimeOnly \"io.github.spair:imgui-java-natives-linux:${imguiVersion}\"\n        runtimeOnly \"io.github.spair:imgui-java-natives-macos:${imguiVersion}\"\n    }\n\n    application {\n        mainClass = 'com.jme3.imgui.TestImGuiApplication'\n    }\n\n    tasks.withType(JavaCompile).configureEach {\n        options.encoding = 'UTF-8'\n    }\n",
  "title": "Vlog 03: Integrating Dear ImGui (1.92.0+) with latest jME3: Initial Findings, Traps, and Architecture Choices"
}