# imgui-rs: Rust bindings for Dear ImGui, and the backend decision they force on you

> imgui-rs wraps Dear ImGui in safe Rust, but it deliberately ships no window and no renderer. Here is what the workspace actually contains, how to get the hello_world example running, and where the crate is the wrong choice.

**imgui-rs/imgui-rs** — Rust bindings for Dear ImGui

- Repository: https://github.com/imgui-rs/imgui-rs
- Stars: 3,057 · Forks: 387
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/imgui-rs-imgui-rs

## The problem imgui-rs solves, and the audience it assumes

Dear ImGui is a C++ library built around one idea: you rebuild the entire interface every frame, inside the same loop that draws your scene, and the library keeps the state for you. imgui-rs exposes that model to Rust through two crates in the workspace, imgui for the high-level safe API and imgui-sys for the automatically generated low-level unsafe API. The README is explicit that API coverage is not 100 percent, so you should expect to reach for imgui-sys occasionally when a widget or flag has not been wrapped yet.

The audience is narrower than the crate name suggests. This is a good fit for debug overlays, internal tools, level editors, profilers and anything where the UI is drawn on top of something else you already render. It is a poor fit for applications whose interface is the product and whose layout is mostly static, because immediate mode rebuilds every widget every frame by design. The builder structs are the other half of the pitch: where the C++ library takes optional function parameters, imgui-rs uses builders, which is why the hello world example reads as a chain rather than a call with positional arguments.

## How the crates split: draw lists out, events in

The README describes a three-part arrangement, and the split is the most important thing to understand before writing any code. imgui-rs itself is renderer-agnostic and platform-agnostic. A backend platform handles the operating system side: it feeds keyboard and mouse events into imgui-rs state, passes window size and DPI factor information in, and updates the OS-side mouse cursor when imgui-rs asks for it. A renderer takes the generic draw lists that imgui-rs produces and turns them into vertex and index buffers, command lists, scissor rects and texture uploads for a specific graphics API.

That means data flows in two directions at once. Input events and window metrics flow from your platform layer into the imgui context; draw lists flow out of the context into your renderer each frame. Nothing in the core crate knows about winit, glow, wgpu or SDL2. The repository lists imgui-glow-renderer, imgui-winit-support and imgui-sdl2-support as official sources that will always be kept up to date and working, and the README states that the most tested combination is imgui-glow-renderer plus imgui-winit-support plus winit. Everything else is community territory. The README warns that community renderers such as imgui-wgpu, imgui-d3d12-renderer and imgui-dx11-renderer may be out of date with imgui-rs releases, and it marks imgui-gfx-renderer and imgui-glium-renderer as deprecated, with the gfx renderer not maintained beyond imgui-rs v0.8. If you pick a community renderer, checking its Cargo.toml against your imgui-rs version is your job, not the project's.

## Installing imgui-rs and running the hello_world example

The README does not give a cargo add line for the core crate, because the core crate alone will not draw anything. The examples live in a separate repository, imgui-examples, and that is the fastest path to a running window. Clone it, then run the test suite from the repository root before running any example.

```bash
git clone https://github.com/imgui-rs/imgui-examples
cd imgui-examples
cargo test
```

The README shows three example names to try, hello_world, test_window and test_window_impl. Running hello_world should open a window containing the text shown in the README's code sample, including a live mouse position read from ui.io().mouse_pos.

```bash
cargo run --example hello_world
cargo run --example test_window
cargo run --example test_window_impl
```

The code you are running is a builder chain. The README's sample opens a window with a size of 300 by 100 and Condition::FirstUseEver, which means the size applies only the first time the window appears, then user resizing takes over.

```rust
ui.window("Hello world")
    .size([300.0, 100.0], Condition::FirstUseEver)
    .build(|| {
        ui.text("Hello world!");
        ui.text("こんにちは世界！");
        ui.text("This...is...imgui-rs!");
        ui.separator();
    });
```

Two constraints bite before you get this far. The README states the MSRV for imgui-rs and all backend crates is 1.82, and the workspace Cargo.toml sets package.rust-version to 1.82, so an older toolchain will fail to build. On Windows, the README says you need the MSVC ABI version of the Rust compiler together with its associated dependencies. If you intend to write your own integration rather than use the examples, you will add the imgui crate plus a backend platform crate and a renderer crate, and the README points you at each backend's Cargo.toml to find compatible glow and glutin versions.

## Where imgui-rs is the wrong tool

The immediate mode model has a cost that the README does not discuss: every widget is rebuilt and re-laid-out each frame, so a form with hundreds of controls keeps doing that work whether or not anything changed. For a debug overlay that is irrelevant. For a settings dialog in a desktop application that runs for hours, it is a design decision you should make deliberately rather than inherit.

The second limitation is the integration surface. imgui-rs will not open a window for you, will not create a graphics context, and will not upload fonts unless your renderer does it. If you are starting a Rust GUI project from scratch and have no existing render loop, you are signing up for window creation, event loop plumbing, renderer setup and DPI handling before the first button appears. The README acknowledges this directly by saying almost every application needs two additional components. The third limitation is coverage. The README states that API coverage is not 100 percent and will keep improving, which is honest but means you should check whether the specific widget or flag you need is wrapped before committing to the crate. Finally, the docking branch is described as optional support rather than the default, so if your design depends on dockable panels you are opting into a non-default configuration.

## imgui-rs versus egui, and the difference that matters

The most common comparison for imgui-rs is egui, and the difference is not cosmetic. Both are immediate mode Rust GUI libraries, so the per-frame rebuild model is shared and the performance characteristics are broadly similar. What differs is what comes in the box. imgui-rs is bindings over an existing C++ library, and it inherits Dear ImGui's separation between core, platform backend and renderer, which is why the README spends several paragraphs telling you to choose a backend platform and a renderer. egui is a Rust-native library with its own ecosystem that does not require you to select a C++-derived backend and renderer pair.

If your application already has a glow, wgpu or SDL2 rendering path and you want an overlay that draws into it, imgui-rs fits that shape well because the draw list boundary is explicit and documented. If you are writing a standalone Rust application and want the shortest path from an empty Cargo.toml to a visible window, the extra component selection is friction you do not need. The other real difference is the C++ dependency: imgui-rs uses Dear ImGui and cimgui under the hood, so your build pulls in native code, which matters if your target platform or your build pipeline makes C++ compilation awkward. The README lists imgui-rs as not tied to any specific graphics or OS API, and that is the trade: flexibility in exchange for assembly.

## Maintenance, releases and what the licence lets you do

The repository is not archived, and the last push was on 2026-06-21. Releases are infrequent rather than continuous: v0.12.0 landed on 2024-05-05, v0.11.0 on 2023-04-05 and v0.10.0 on 2023-01-16. That cadence matters for planning. The README states that the MSRV is updated periodically with a minor version bump, so a minor release can raise your required toolchain, and the crate wraps a pinned Dear ImGui version, shown in the README badge as 1.89.2, so upstream Dear ImGui features arrive on the project's schedule rather than upstream's.

Upgrade cost is concentrated in the backend and renderer crates. Because imgui-glow-renderer, imgui-winit-support and imgui-sdl2-support are versioned separately from imgui itself, bumping imgui does not automatically bump them, and the README tells you to read each Cargo.toml to find compatible glow and glutin versions. Budget for that check on every upgrade. Community renderers carry more risk: the README says they may be out of date with imgui-rs releases, and it explicitly lists imgui-gfx-renderer as deprecated and not maintained beyond imgui-rs v0.8.

On licensing, the README says the project is licensed under either Apache License 2.0 or the MIT license, at your option, and the repository root contains LICENSE-APACHE and LICENSE-MIT. Contributions are dual licensed the same way unless stated otherwise. Note that the underlying Dear ImGui and cimgui projects carry their own licences, which are separate from imgui-rs and are not described in this README, so check them if licence compatibility drives your decision.

## Conclusion

Adopt imgui-rs if you want Dear ImGui's immediate mode model in safe Rust and you are prepared to pick a backend platform and a renderer yourself; the README names imgui-glow-renderer plus imgui-winit-support as the most tested combination. Do not adopt it if you want a single crate that opens a window, or if your UI is a long-lived application shell that would benefit from retained widgets. Verify first that your toolchain is at Rust 1.82 or newer, that you are using the MSVC ABI on Windows, and that the renderer crate you intend to use lists a compatible version for your imgui-rs release.

## FAQ

### Can you explain what imgui-rs is?

imgui-rs provides Rust bindings to Dear ImGui, the immediate mode user interface library. The workspace contains imgui, a high-level safe API, and imgui-sys, an automatically generated low-level unsafe API.

### What are the downsides of using imgui-rs?

The README states that API coverage is not 100 percent, so some Dear ImGui functionality is only reachable through imgui-sys. It also says almost every application needs a separate backend platform and renderer, which you must select and version yourself.

### Is imgui-rs good for game UI?

The README positions imgui-rs as renderer-agnostic and platform-agnostic, with imgui-glow-renderer plus imgui-winit-support plus winit as the most tested combination. That suits overlays and tools drawn alongside an existing render loop, but the README does not make any claim about game UI specifically.

### Can I use imgui-rs with Python?

No. imgui-rs is a Rust crate, and the README describes it as Rust bindings to Dear ImGui, with a minimum supported Rust version of 1.82. The README does not mention any Python binding.

## Sources

- [imgui-rs/imgui-rs on GitHub](https://github.com/imgui-rs/imgui-rs)
- [Issues](https://github.com/imgui-rs/imgui-rs/issues)
- [License: Apache-2.0](https://github.com/imgui-rs/imgui-rs/blob/main/LICENSE)
- [README](https://github.com/imgui-rs/imgui-rs/blob/main/README.md)
- [Releases](https://github.com/imgui-rs/imgui-rs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imgui-rs-imgui-rs