Dear ImGui: an immediate mode C++ UI library for tools, not end users

The problem Dear ImGui solves, and who it is written for

Most GUI toolkits keep a widget tree alive between frames. You build a dialog once, store a pointer to each control, and later read the control's value back out. That is the right model for a word processor. It is a poor model for a debug overlay, where the thing you want to display is a variable that already exists in your program and changes sixty times a second.

Dear ImGui inverts that. The README describes it as a "bloat-free graphical user interface library for C++" that outputs optimized vertex buffers you render in your own 3D pipeline. The intended audience is stated plainly: programmers building "content creation tools and visualization / debug tools (as opposed to UI for the average end-user)". The README names game engines, real-time 3D applications, fullscreen applications, embedded applications and console platforms as the places it fits best.

That framing is not marketing modesty, it is a scope decision. The same README says full internationalization (right-to-left text, bidirectional text, text shaping) and accessibility features are not supported. If your users need a screen reader, this library is the wrong starting point, and no amount of backend work fixes it.

How the immediate mode loop actually works

There is no retained widget tree to keep in sync with your data. Each frame you call functions such as ImGui::Text, ImGui::Button and ImGui::SliderFloat, and those calls both draw the widget and return its current state. The README's own example shows the pattern: ImGui::Button("Save") returns a bool, and you call your save function when it is true. The slider writes into a float you already own.

The library then emits vertex buffers and a command list. According to the README, the number of draw calls and state changes needed to render them is fairly small, and Dear ImGui does not know or touch graphics state directly, which is why it can sit inside an existing renderer rather than owning the frame.

The core itself is a handful of platform-agnostic files in the repository root: imgui.cpp, imgui_draw.cpp, imgui_tables.cpp, imgui_widgets.cpp and the matching headers, plus imconfig.h for compile-time configuration. Everything platform-specific lives in backends/, which contains integrations for GLFW, SDL2, SDL3, Vulkan, Metal, DirectX 11, Allegro5, GLUT, QNX, WGPU and more. The examples/ directory pairs a windowing library with a graphics API, for instance example_glfw_opengl3, example_sdl3_directx11 and example_apple_metal.

The trade-off is real. The README quotes a line about state duplication being a lifetime bug source, and the immediate mode design is the answer to it. The cost is that any state you do need, such as which panel is open, lives in your variables and is rebuilt from scratch each frame. For a tool that is a feature. For a form with thirty fields and undo history, it is work you now do yourself.

Installing Dear ImGui and running the GLFW OpenGL3 example

There is no package to install and no build system to adopt. The README states that the core files are self-contained and that no specific build process is required: you add the root .cpp and .h files to your existing project. The examples exist so you can see a working configuration before wiring it into your own engine.

Start by cloning the repository and looking at the example that matches your platform. The GLFW plus OpenGL3 example is the one most people try first, and its source files live under examples/example_glfw_opengl3.

git clone https://github.com/ocornut/imgui
cd imgui/examples/example_glfw_opengl3

That directory contains its own build files for several toolchains. The README does not spell out the commands, so read what is actually in the folder before running anything; the example ships a Makefile and project files for Visual Studio and CMake-based builds. A typical CMake flow from that directory looks like the block below, but confirm the target names against the example's own CMakeLists.txt.

cmake -B build
cmake --build build

Once it runs you get a window showing the Dear ImGui demo, which is compiled from imgui_demo.cpp in the repository root. That file is the real documentation for the widget set: every control the library offers is exercised there, and reading it is faster than hunting for prose. To put your own code in, the README's first snippet is the shortest useful thing to type:

ImGui::Text("Hello, world %d", 123);
if (ImGui::Button("Save"))
    MySaveFunction();
ImGui::InputText("string", buf, IM_COUNTOF(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);

Those four calls go inside your frame loop between the backend's NewFrame and Render calls. The text is drawn, the button returns true on the frame it is clicked, the input writes into your buffer and the slider writes into your float. Nothing is stored on the library side.

Where Dear ImGui is the wrong tool

The README is unusually direct about the limits, and it is worth taking at face value. Full internationalization is not supported: right-to-left text, bidirectional text and text shaping are absent. Accessibility is absent. If you are shipping a product to a general audience in Arabic or Hebrew, or you need to pass an accessibility audit, this library will not get you there and the gap is architectural rather than a missing flag.

The second limitation is that you supply the rendering and the platform layer. Dear ImGui does not create a window, does not open a graphics device and does not read input events on its own. The backends handle that, and if none of the backends matches your setup you write your own. The README's rule of thumb is that anywhere you can render textured triangles, you can render Dear ImGui, which is encouraging until you are on a platform where you cannot.

The third is state ownership. Because the UI is rebuilt every frame, anything that must survive a frame, including scroll positions you care about, selection indices and undo stacks, is your responsibility. The library keeps some internal state, but the README's stated goal is to minimize state retention on the user side, not to eliminate the need for it.

Finally, the project asks for funding. The README says the library is under a permissive license but needs financial support to sustain continued improvements, and notes that many desirable features are still to be added. That is a maintenance reality to weigh, not a defect.

Dear ImGui compared with Qt Widgets and a hand-rolled overlay

The nearest alternative for C++ desktop tooling is Qt Widgets. The difference in approach is the state model. Qt builds a widget tree once, keeps it alive, and connects signals to slots; you describe the interface and then mutate it. Dear ImGui rebuilds the interface every frame from variables you already have, so there is no tree to keep in sync and no signal wiring to trace. Qt also gives you native windowing, accessibility, internationalization and a designer tool, none of which Dear ImGui provides. If your tool must look like a native desktop application, Qt is the shorter path. If your tool must draw inside your own OpenGL or Vulkan frame, Qt is the harder integration.

The other alternative is drawing your own overlay with the graphics API directly. That gives you total control over appearance and zero dependency, and it is what many engines did before adopting an immediate mode library. The cost is that every checkbox, text field and scroll region is code you write and maintain. Dear ImGui's value is the widget set in imgui_widgets.cpp plus the backend matrix in backends/, which is a large amount of platform-specific code you do not write.

For language bindings, the repository points to a wiki page listing bindings and framework backends, and the README mentions a third-party C++20 module at stripe2933/imgui-module. If you are not writing C++, that page is where to start, because the core library is C++ and the bindings are maintained outside this repository.

Maintenance, releases and what the MIT license means here

The repository is not archived and the last push was on 2026-07-31. Recent releases are v1.92.8 on 2026-05-12, v1.92.9 on 2026-07-25 and v1.92.9b on 2026-07-31. That cadence matters for upgrade planning: point releases arrive often, and the README points readers to the Releases and Changelogs section rather than describing a stability policy.

The practical upgrade cost depends on how you consume the library. If you copy the root source files into your project, as the README suggests, upgrading means replacing those files and rebuilding. If you vendor a specific tag, you control when that happens. Either way the API surface you touch is small, which keeps the diff readable, but the README does not document a rollback procedure, so keeping your previous copy is the only fallback the repository supports.

The license is MIT, per the LICENSE.txt file in the repository root. That permits commercial use and modification, and it requires that the license text be preserved. It says nothing about the funding request in the README, which is a separate, voluntary matter. This is a description of the license identifier, not legal advice; read LICENSE.txt yourself before shipping.

One more maintenance note from the repository layout: the stb-derived files imstb_rectpack.h, imstb_textedit.h and imstb_truetype.h are vendored copies, not external dependencies. The README's claim of no external dependencies holds because those files are checked in.

Editorial conclusion

Adopt Dear ImGui if you are writing a C++ tool that lives inside your own render loop, such as an engine inspector, a profiler overlay or an internal editor, and you accept that you own the window, the graphics API and the input plumbing. Do not adopt it for a consumer desktop application that needs screen reader support, right-to-left text or bidirectional text shaping, because the README states those features are not supported. Before committing, verify three things in the repository: that a backend under backends/ matches your graphics API, that an example under examples/ matches your platform and windowing library, and what the release notes for v1.92.9b changed, since that is the most recent release and the README does not document a rollback path between versions.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes