# imgui_club: three official Dear ImGui extensions and how they fit in a project

> imgui_club is the MIT licensed repository of officially maintained small extensions for Dear ImGui, holding a hexadecimal memory editor, a multi-context compositor and a threaded rendering helper. There is no package to install: the top level holds three source directories and a README, and the extensions are meant to be dropped into a project.

**ocornut/imgui_club** — Small extensions for Dear ImGui

- Repository: https://github.com/ocornut/imgui_club
- Stars: 1,150 · Forks: 119
- Language: C
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/ocornut-imgui-club

## Three directories, no build system

imgui_club is a small collection of officially maintained extensions for Dear ImGui, and the repository layout says most of what you need to know about how it is consumed.

The top level contains.editorconfig, LICENSE.txt, README.md, and three directories: imgui_memory_editor/, imgui_multicontext_compositor/ and imgui_threaded_rendering/. There is no CMakeLists, no package manifest, no build script and no CI configuration.

That absence is the distribution model rather than an oversight. Dear ImGui is a library you vendor into your own project. An extension for it is therefore naturally a set of source files and a header you copy in, and imgui_club is a curated place to get those from rather than a library you depend on. The three directory names in the repository listing map exactly onto the three features in the README's index.

The README is short because the extensions are small. It opens with an index of the three, points at the main Dear ImGui wiki for many useful third-party snippets, and gives one section per extension with a description, a link to its directory, and in one case a usage snippet. The licence is MIT, the primary language is C, the repository is not archived, and the last push was on 2026-08-23. There are no GitHub releases, which is consistent with there being nothing to release.

## The memory editor is a hex view with a read and write hook

The memory editor is described in one line as a mini hexadecimal editor where you right-click for an option menu, and the feature list is the interesting part.

It has keyboard controls, a read-only mode, optional Ascii display and optional HexII display, a goto address function, highlight range and highlight function, and read and write handlers.

The usage is a static instance and a draw call:

```cpp
static MemoryEditor mem_edit;
mem_edit.DrawWindow("Memory Editor", data, data_size);
```

Two things follow from that snippet. The editor is a stateful object with a static instance, so it keeps its scroll position, its current address and its highlight state across frames, which is what makes it usable as a persistent panel rather than a one-shot dump. And the draw call takes a raw pointer and a size, so it inspects memory the host program owns, which is exactly what a debugger-style panel needs.

The read and write handlers are the feature to look at carefully. An editor that can only read is a viewer, which is safe to ship. An editor that can write is a debugger, and the host program has to supply the handler that actually performs the write, along with whatever validation it wants. The read-only mode exists alongside them, so a program can expose the view without exposing mutation.

The README links two images of the memory editor.

## The multi-context compositor solves the z-order problem

The multi-context compositor is for the case where you are using and displaying multiple ImGui contexts simultaneously, with the example given being an Update domain against a Rendering domain.

That situation is real and specific. When an application has more than one Dear ImGui context, each context has its own windows, its own draw data and its own idea of what is on top. Rendering two contexts into one frame means deciding three things, and the compositor is responsible for all three.

First, the z-order of contexts, so the context you want on top is genuinely on top rather than whichever happened to be drawn last. Second, the input routing, so a click goes to the context that owns the window under the cursor rather than to the first context that asks for it. Third, drag and drop between contexts, so a payload dragged out of a window in one context can be dropped into a window in another.

The third of those is the most involved, because drag and drop is a multi-frame interaction and the two contexts have to agree on which payload is in flight. Doing that by hand across two independent contexts is the kind of thing that produces a demo that works and a shipped application that does not, so a maintained helper for it is worth having.

The name compositor is the right one. Dear ImGui itself composites the windows of a single context, and this extends that idea across contexts, which is a reasonable place to draw the line for a small extension.

## The threaded rendering helper is a snapshot, not a queue

The threaded rendering extension is described in one sentence: a helper to take a snapshot of ImDrawData in order to render it later.

The mechanism implied by that description is worth spelling out, because it is the standard solution to a specific problem. Dear ImGui builds its draw data on the thread that runs the UI logic, and that draw data is only valid until the next frame overwrites it. If you want to render on a different thread, you cannot simply hand the pointer across, because the producing thread will mutate it while the consumer reads it.

So you take a snapshot. The draw data is copied at a point in the frame when it is stable, and the copy is what the rendering thread consumes. The cost is a copy per frame, and the benefit is that the render thread never touches data the UI thread is mutating, and never has to wait for it.

That trade is worth making in exactly the situation this extension targets, which is an application whose UI thread is doing work that would stall rendering, or whose rendering needs to happen at a different cadence from the UI update. A copy of a few thousand draw commands is cheap compared to a frame hitch.

The other thing a snapshot buys is determinism. The rendering thread renders a frame that was captured, not a frame that is being mutated, so a dropped frame or a reordering in the render queue does not produce a torn or inconsistent image.

## What you get and what you do not

The scope here is small and that is the point, so it is worth being explicit about the boundaries.

You get three things. A hexadecimal memory inspector for a running application, a way to display and route input across several Dear ImGui contexts at once, and a snapshot helper for off-thread rendering. Each one is a solved problem that would otherwise be a small custom subsystem in your codebase.

You do not get a build system, a package manager entry, a documentation site, or a set of widgets. The README is an index with a description per extension, and the extension directories are where the code lives. The reference for the main library's own documentation is the Dear ImGui wiki, and the README points there for many useful third-party snippets, which is the honest division of labour: the wiki collects community contributions, this repository holds the ones the author maintains.

There is also no release cadence in the GitHub sense, since there are no GitHub releases. The three extension directories are updated in place, and the last push was on 2026-08-23. For a library you vendor, that model is normal and low risk, because you copy the files and they do not change under you until you choose to copy again.

The one genuine risk in the set is the memory editor's write path. The library gives you the panel and the plumbing, and the host program provides the handler that actually mutates memory. If your application exposes that panel to end users rather than to developers, the validation of that handler is entirely your responsibility, and a hex editor that can write anywhere in a buffer is a sharp tool to expose by accident.

## Conclusion

imgui_club is a good pick for a Dear ImGui project that needs a memory inspector, a way to display several ImGui contexts at once, or off-thread rendering, because these are the extensions the library author maintains himself rather than community forks; it is the wrong pick if you want a package manager entry or a documented install path, since the repository ships three source directories with no build files, and before you adopt the memory editor you should note that it can write to memory, so the read and write handlers are the part that needs care in anything you ship.

## FAQ

### What is in the imgui_club repository?

Three officially maintained Dear ImGui extensions in separate directories: imgui_memory_editor, a mini hexadecimal editor; imgui_multicontext_compositor, for managing z-order, input routing and drag and drop between multiple contexts; and imgui_threaded_rendering, a helper to snapshot ImDrawData so it can be rendered later.

### How do I install imgui_club?

There is no install step. The repository ships three source directories and a README, with no build files or package manifest, so the extensions are added to your project the way Dear ImGui itself is, by vendoring the sources. The README also points to the Dear ImGui wiki for third-party snippets.

### How do I use the imgui_club memory editor?

Declare a static instance and draw it with a pointer and a size: static MemoryEditor mem_edit; mem_edit.DrawWindow("Memory Editor", data, data_size). It has keyboard controls, a read-only mode, optional Ascii and HexII display, a goto address, highlight range and function, and read and write handlers that the host program supplies.

### What does the imgui_club multi-context compositor handle?

When multiple Dear ImGui contexts are displayed simultaneously, such as an Update domain against a Rendering domain, it manages the z-order of contexts, routes input to the right context, and allows drag and drop between contexts.

### What licence is imgui_club released under?

MIT, with the licence text in LICENSE.txt at the repository root. The primary language is C, the repository is not archived, the last push was on 2026-08-23, and there are no GitHub releases.

## Sources

- [Issues](https://github.com/ocornut/imgui_club/issues)
- [License: MIT](https://github.com/ocornut/imgui_club/blob/main/LICENSE)
- [ocornut/imgui_club on GitHub](https://github.com/ocornut/imgui_club)
- [README](https://github.com/ocornut/imgui_club/blob/main/README.md)

---

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