- ImGui (Dear ImGui) is a small immediate-mode GUI library for C++.
- It draws the menu fresh every frame from function calls, with no widget tree to maintain.
- Native clients and tools pick it for low-latency overlays over a 3D scene.
- It is a C++ pattern; a Java Fabric mod uses the game's own GUI hooks instead.
ImGui, short for Dear ImGui, is a small immediate-mode GUI library for C++. It draws a menu fresh every frame from plain function calls instead of keeping a tree of widget objects around. That makes it fast to wire up and easy to drop on top of a game's existing render loop, which is why tooling and native clients use it for low-latency overlays.
Where Opal fits
Opal is a Fabric mod, so it builds its interface through the game's own GUI hooks rather than ImGui. If you want to add features without touching native code, the GraalVM JavaScript scripting engine is the place to start. See the setup guide and the scripting guide.
What immediate-mode means
ImGui rebuilds the interface on every frame. You do not create a button object and store it. You call a function that says "draw a button here," and that call both draws the button and tells you whether it was clicked this frame.
A retained-mode toolkit works the other way. It keeps a long-lived widget tree in memory, and you update that tree when state changes. Immediate-mode trades that persistent structure for code that reads top to bottom and lives next to your own state.
Why tools and clients pick it
ImGui is popular for menus that sit over a 3D scene. The reasons are practical.
- Low latency: it hooks into a frame the program already renders, so the menu reacts right away.
- Little glue: a window and a few controls are a handful of function calls. There is no layout file and no separate UI thread to manage.
- Self-contained: the library has few dependencies and slots into common graphics backends, so it does not pull in a heavy framework.
- Debug-friendly: the same calls that build a release menu also build the throwaway debug panels developers use while building a feature.
Immediate-mode vs retained-mode
| Aspect | Immediate-mode (ImGui) | Retained-mode toolkit |
|---|---|---|
| State ownership | Your code holds the data | The toolkit holds a widget tree |
| Per-frame work | Rebuild the UI each frame | Update the tree on change |
| Setup cost | A few function calls | More structure up front |
| Best fit | Overlays, tools, game menus | Large document-style apps |
How it fits a native client
A native utility client built in C++ often draws its menu with ImGui over the game's frame. The menu code runs inside the render loop, reads the client's own settings, and writes changes straight back. There is no separate UI process, so toggling a feature is one function call against a value the client already owns.
This is a C++ pattern. A Fabric mod written in Java reaches its interface through the game's own GUI hooks instead, so ImGui mostly shows up in clients that ship as native code rather than as Java mods.
FAQ
The core library is C++, and that is where most projects use it. Community bindings exist for other languages, but the original and most common use is in C++ game tools and native applications.
Out of the box it has a plain developer-tool look. Projects that want a custom style theme it heavily or draw their own widgets on top, so a shipped menu can look nothing like the default.
Not in the usual way. A Fabric mod runs in Java and uses the game's GUI system. A native C++ client is the typical home for ImGui.
No. Rebuilding the UI is cheap, and the program already renders every frame, so the menu rides along on work that is happening anyway.
