Learn · concepts
What Is ImGui? Dear ImGui Explained
ImGui (Dear ImGui) is an immediate-mode GUI library for C++. It draws menus every frame with no retained widget tree, common in game tools and native clients.
What is ImGui?
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.
The key insight is "immediate-mode": instead of creating a Button object and storing 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.
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.
Application runs frame loop
The game renders a frame and calls the UI code as part of it.
UI code runs
You call ImGui functions to build the menu from top to bottom: buttons, sliders, checkboxes.
ImGui draws and responds
The functions both render the widgets and return whether they were interacted with this frame.
Your code reacts
You read the return values and update your own state, like calling
do_thing()when the button was clicked this frame.
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 doesn't 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 |
Immediate-mode is ideal for something that needs to update every frame and respond to input instantly. Retained-mode is better for something that sits mostly static and changes rarely.
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's 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's where most projects use it. Community bindings exist for other languages, but the original and most common use is in C++ game tools.
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.
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's happening anyway.