ocornut/imgui

Dear ImGui is a C++ graphical interface library aimed at programmers who need tooling inside their own application rather than a finished end-user UI. It is most relevant when you already have a rendering loop—a game engine, real-time 3D app, console, or embedded target—and want debug panels, inspectors, profilers or small authoring tools with little setup and no external dependencies. It is explicitly less suited to conventional end-user interfaces: full internationalization (right-to-left and bidirectional text, text shaping) and accessibility are not supported.

The workflow and what changes

You add the core imgui*.cpp / imgui*.h files directly to your existing project and call widgets from wherever you need them in your program loop. Integration centers on three things: forwarding mouse, keyboard and gamepad input; supplying texture data; and providing a render function—the same work the provided backends already do (repository README). The README describes this as typically taking under an hour in a codebase where support libraries are linked.

How it produces the result

This is an immediate-mode API: the UI is described in code each frame rather than stored in a long-lived widget tree the library owns. In the library's framing, this reduces duplicated state and synchronization between application state and UI state. Widgets return values the application reacts to in place, so a slider can bind directly to a float and a button can call a function. Dear ImGui does not manage graphics state itself; it emits vertex buffers and a small number of draw-call batches that your renderer executes, so calls can sit anywhere in your own rendering code, including mid-algorithm (How it works). The library also points out that this is not the same as immediate-mode rendering, where each GUI call would hit the GPU.

The practical payoff is short-lived tooling: with a compiler's Edit & Continue feature you can add a few widgets to tweak live variables and remove them a minute later, without a separate UI file or binding layer.

Paths and prerequisites

The core route is C++. Officially maintained backends cover renderers such as DirectX 9–12, Metal, OpenGL/ES, SDL_GPU, SDL_Renderer, Vulkan and WebGPU, and platforms such as GLFW, SDL2/SDL3, Win32, GLUT, macOS and Android (BACKENDS guide). Other languages are reachable through third-party bindings, which are listed for C, C#, Rust, Go, Python, Java, Zig and many more (bindings wiki); these are separate projects, so support and platform coverage depend on each binding, not on the core library. C++20 module users are directed to a third-party module extension. A browser-based demo with a source browser is available for a look before integrating (demo section).

Constraints to know

• The target UI is tools and debugging, not average end-user software; the README explicitly excludes full internationalization and accessibility.
• You must supply a rendering backend and input plumbing, or write your own where no official backend exists.
• The project recommends syncing to the latest master or docking branch; tagged releases exist, but the docking branch holds multi-viewport and docking features and is kept in sync regularly (repository README).
• It is MIT-licensed (LICENSE) and describes itself as needing financial support to sustain improvements, with optional paid support via invoiced contracts or funding pages.

An HN commenter in 2020 noted that immediate-mode UI can require continuous frame rendering or extra state tracking for apps that rarely redraw, saying it fits games better than idle desktop applications (HN discussion). That is a design-fit consideration, and the library's own documentation targets real-time and tooling contexts.