Also see: [Links to many articles about the IMGUI paradigm](https://github.com/ocornut/imgui/wiki/#about-the-imgui-paradigm). +See also: [articles about the IMGUI paradigm](https://github.com/ocornut/imgui/wiki/#about-the-imgui-paradigm). -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: Which version should I get? -I occasionally tag [Releases](https://github.com/ocornut/imgui/releases) but it is generally safe and recommended to sync to master/latest. The library is fairly stable and regressions tend to be fixed fast when reported. +### Which version should I get? -You may use the ['docking'](https://github.com/ocornut/imgui/tree/docking) branch which includes: -- [Docking features](https://github.com/ocornut/imgui/wiki/Docking) -- [Multi-viewport features](https://github.com/ocornut/imgui/wiki/Multi-Viewports) +[Releases](https://github.com/ocornut/imgui/releases) are tagged occasionally with changelogs, but syncing to `master` is generally safe and recommended — the library is stable and regressions are fixed quickly. -Many projects are using this branch and it is kept in sync with master regularly. +Advanced users may prefer the [`docking`](https://github.com/ocornut/imgui/tree/docking) branch, which adds: +- [Docking](https://github.com/ocornut/imgui/wiki/Docking) +- [Multi-viewport support](https://github.com/ocornut/imgui/wiki/Multi-Viewports) -##### [Return to Index](#index) +It's used by many projects and kept regularly in sync with `master`. ----- - -# Q&A: Integration - -### Q: How to get started? - -Read [Getting Started](https://github.com/ocornut/imgui/wiki/Getting-Started).
-Read [docs/EXAMPLES.md](https://github.com/ocornut/imgui/blob/master/docs/EXAMPLES.md).
-Read [docs/BACKENDS.md](https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md).
-Read `PROGRAMMER GUIDE` section of [imgui.cpp](https://github.com/ocornut/imgui/blob/master/imgui.cpp).
-The [Wiki](https://github.com/ocornut/imgui/wiki) is a hub to many resources and links. - -For first-time users having issues compiling/linking/running or issues loading fonts, please use [GitHub Discussions](https://github.com/ocornut/imgui/discussions). - -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: How can I tell whether to dispatch mouse/keyboard to Dear ImGui or my application? +## Integration -You can read the `io.WantCaptureMouse`, `io.WantCaptureKeyboard` and `io.WantTextInput` flags from the ImGuiIO structure. -- When `io.WantCaptureMouse` is set, you need to discard/hide the mouse inputs from your underlying application. -- When `io.WantCaptureKeyboard` is set, you need to discard/hide the keyboard inputs from your underlying application. -- When `io.WantTextInput` is set, you can notify your OS/engine to popup an on-screen keyboard, if available (e.g. on a mobile phone, or console OS). +### How to get started? -Important: you should always pass your mouse/keyboard inputs to Dear ImGui, regardless of the value `io.WantCaptureMouse`/`io.WantCaptureKeyboard`. This is because e.g. we need to detect that you clicked in the void to unfocus its own windows, and other reasons. +- [Getting Started](https://github.com/ocornut/imgui/wiki/Getting-Started) wiki guide +- [docs/EXAMPLES.md](https://github.com/ocornut/imgui/blob/master/docs/EXAMPLES.md) +- [docs/BACKENDS.md](https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md) +- The `PROGRAMMER GUIDE` section at the top of [imgui.cpp](https://github.com/ocornut/imgui/blob/master/imgui.cpp) +- The [Wiki](https://github.com/ocornut/imgui/wiki) generally + +Stuck on compiling, linking, running, or fonts? Ask in [GitHub Discussions](https://github.com/ocornut/imgui/discussions). + +[↑ Back to top](#table-of-contents) + +--- + +### Should input go to Dear ImGui or my application? + +Check the `io.WantCaptureMouse`, `io.WantCaptureKeyboard`, and `io.WantTextInput` flags on `ImGuiIO`: + +- `io.WantCaptureMouse` set → discard/hide mouse input from your app. +- `io.WantCaptureKeyboard` set → discard/hide keyboard input from your app. +- `io.WantTextInput` set → good time to pop up an on-screen keyboard (mobile/console). + +**Important:** always forward raw mouse/keyboard input to Dear ImGui regardless of these flags — it needs the full stream to, e.g., detect clicks outside its own windows. ```cpp void MyLowLevelMouseButtonHandler(int button, bool down) { - // (1) ALWAYS forward mouse data to ImGui! This is automatic with default backends. With your own backend: + // (1) ALWAYS forward mouse data to ImGui! Automatic with default backends. With a custom backend: ImGuiIO& io = ImGui::GetIO(); io.AddMouseButtonEvent(button, down); - // (2) ONLY forward mouse data to your underlying app/game. + // (2) ONLY forward to your app/game if ImGui doesn't want it. if (!io.WantCaptureMouse) my_game->HandleMouseData(...); } ``` -**Note:** The `io.WantCaptureMouse` is more correct that any manual attempt to "check if the mouse is hovering a window" (don't do that!). It handles mouse dragging correctly (both dragging that started over your application or over a Dear ImGui window) and handle e.g. popup and modal windows blocking inputs. +**Notes:** +- `io.WantCaptureMouse` is more reliable than manually checking "is the mouse over a window" — it correctly handles dragging (started inside or outside ImGui) and popup/modal blocking. +- Text input releases focus on the Return key's "KeyDown" event, so the following "KeyUp" may arrive with `io.WantCaptureKeyboard == false`. If that's inconvenient, track which key-downs targeted Dear ImGui (e.g., a bool array) and filter the matching key-ups. -**Note:** Text input widget releases focus on the "KeyDown" event of the Return key, so the subsequent "KeyUp" event that your application receive will typically have `io.WantCaptureKeyboard == false`. Depending on your application logic it may or not be inconvenient to receive that KeyUp event. You might want to track which key-downs were targeted for Dear ImGui, e.g. with an array of bool, and filter out the corresponding key-ups.) - -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: How can I enable keyboard or gamepad controls? -- The gamepad/keyboard navigation is fairly functional and keeps being improved. The initial focus was to support game controllers, but keyboard is becoming increasingly and decently usable. Gamepad support is particularly useful to use Dear ImGui on a game console (e.g. PS4, Switch, XB1) without a mouse connected! -- Keyboard: set `io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard` to enable. -- Gamepad: set `io.ConfigFlags |= ImGuiConfigFlags_NavEnableGamepad` to enable (with a supporting backend). -- See [Control Sheets for Gamepads](https://www.dearimgui.com/controls_sheets) (reference PNG/PSD for PS4, XB1, Switch gamepads). -- See `USING GAMEPAD/KEYBOARD NAVIGATION CONTROLS` section of [imgui.cpp](https://github.com/ocornut/imgui/blob/master/imgui.cpp) for more details. +### How can I enable keyboard or gamepad controls? -##### [Return to Index](#index) +- Gamepad/keyboard navigation is actively developed and improving. It's especially useful for console platforms (PS4, Switch, Xbox One) without a mouse. +- Keyboard: `io.ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard` +- Gamepad: `io.ConfigFlags |= ImGuiConfigFlags_NavEnableGamepad` (needs a supporting backend) +- Reference: [Gamepad control sheets](https://www.dearimgui.com/controls_sheets) (PS4, XB1, Switch) +- Details: `USING GAMEPAD/KEYBOARD NAVIGATION CONTROLS` section in [imgui.cpp](https://github.com/ocornut/imgui/blob/master/imgui.cpp) + +[↑ Back to top](#table-of-contents) --- -### Q: How can I use this on a machine without mouse, keyboard or screen? (input share, remote display) -- You can share your computer mouse seamlessly with your console/tablet/phone using solutions such as [Synergy](https://symless.com/synergy) -This is the preferred solution for developer productivity. -In particular, the [micro-synergy-client repository](https://github.com/symless/micro-synergy-client) has simple -and portable source code (uSynergy.c/.h) for a small embeddable client that you can use on any platform to connect -to your host computer, based on the Synergy 1.x protocol. Make sure you download the Synergy 1 server on your computer. -Console SDK also sometimes provide equivalent tooling or wrapper for Synergy-like protocols. -- Game console users: consider emulating a mouse cursor with DualShock4 touch pad or a spare analog stick as a mouse-emulation fallback. -- You may also use a third party solution such as [netImgui](https://github.com/sammyfreg/netImgui), [Remote ImGui](https://github.com/JordiRos/remoteimgui) or [imgui-ws](https://github.com/ggerganov/imgui-ws) which sends the vertices to render over the local network, allowing you to use Dear ImGui even on a screen-less machine. See [Wiki](https://github.com/ocornut/imgui/wiki) index for most details. -- For touch inputs, you can increase the hit box of widgets (via the `style.TouchPadding` setting) to accommodate for the lack of precision of touch inputs, but it is recommended you use a mouse or gamepad to allow optimizing for screen real-estate and precision. +### Using Dear ImGui without a mouse, keyboard, or screen -##### [Return to Index](#index) +- Share your computer's mouse/keyboard with a console/tablet/phone via [Synergy](https://symless.com/synergy) — the preferred option for dev productivity. The [micro-synergy-client](https://github.com/symless/micro-synergy-client) repo has a small, portable client (uSynergy.c/.h) implementing the Synergy 1.x protocol; pair it with a Synergy 1 server. Console SDKs sometimes offer similar tooling. +- On consoles, emulate a mouse cursor with a touchpad or spare analog stick as a fallback. +- For remote/screen-less rendering, third-party solutions send vertices over the network: [netImgui](https://github.com/sammyfreg/netImgui), [Remote ImGui](https://github.com/JordiRos/remoteimgui), [imgui-ws](https://github.com/ggerganov/imgui-ws). See the [Wiki](https://github.com/ocornut/imgui/wiki) for more. +- For touch input, increase widget hit boxes via `style.TouchPadding`, though a mouse or gamepad is still recommended for precision and screen real estate. + +[↑ Back to top](#table-of-contents) --- -### Q: How can I create my own backend? -- See [docs/BACKENDS.md](https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md). -- See Documentation at the top of imgui.cpp. +### How can I create my own backend? -##### [Return to Index](#index) +See [docs/BACKENDS.md](https://github.com/ocornut/imgui/blob/master/docs/BACKENDS.md) and the documentation at the top of `imgui.cpp`. + +[↑ Back to top](#table-of-contents) --- -### Q: I integrated Dear ImGui in my engine and little squares are showing instead of text... -Your renderer backend is not using the font texture correctly or it hasn't been uploaded to the GPU. -- If this happens using standard backends (before 1.92): A) have you modified the font atlas after `ImGui_ImplXXX_NewFrame()`? B) maybe the texture failed to upload, which **can if your texture atlas is too big**. Also see [docs/FONTS.md](https://github.com/ocornut/imgui/blob/master/docs/FONTS.md). -- If this happens using standard backends (after 1.92): please report. -- If this happens with a custom backend: make sure you have uploaded the font texture to the GPU, that all shaders are rendering states are setup properly (e.g. texture is bound). Compare your code to existing backends and use a graphics debugger such as [RenderDoc](https://renderdoc.org) to debug your rendering states. +### Little squares showing instead of text -##### [Return to Index](#index) +Your renderer backend isn't using the font texture correctly, or it was never uploaded to the GPU. + +- **Standard backend, before 1.92:** (a) did you modify the font atlas after `ImGui_ImplXXX_NewFrame()`? (b) the texture upload may have failed, which can happen if the atlas is too large — see [docs/FONTS.md](https://github.com/ocornut/imgui/blob/master/docs/FONTS.md). +- **Standard backend, after 1.92:** please file a report — this shouldn't happen. +- **Custom backend:** confirm the font texture is uploaded to the GPU and that shader/render state is set up correctly (texture bound, etc.). Compare against an existing backend, and use a graphics debugger like [RenderDoc](https://renderdoc.org). + +[↑ Back to top](#table-of-contents) --- -### Q: I integrated Dear ImGui in my engine and some elements are clipping or disappearing when I move windows around... -### Q: I integrated Dear ImGui in my engine and some elements are displaying outside their expected windows boundaries... -You are probably mishandling the clipping rectangles in your render function. -Each draw command needs the triangle rendered using the clipping rectangle provided in the ImDrawCmd structure (`ImDrawCmd->CllipRect`). -Rectangles provided by Dear ImGui are defined as -`(x1=left,y1=top,x2=right,y2=bottom)` -and **NOT** as -`(x1,y1,width,height)`. -Refer to rendering backends in the [backends/](https://github.com/ocornut/imgui/tree/master/backends) folder for references of how to handle the `ClipRect` field. -For example, the [DirectX11 backend](https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_dx11.cpp) does this: +### Elements clipping / displaying outside window boundaries + +Usually a mishandled clipping rectangle in your render function. + +Each draw command's clip rectangle (`ImDrawCmd->ClipRect`) is defined as `(x1=left, y1=top, x2=right, y2=bottom)` — **not** `(x1, y1, width, height)`. + +See any backend in [backends/](https://github.com/ocornut/imgui/tree/master/backends) for reference. DirectX11 example: + ```cpp // Project scissor/clipping rectangles into framebuffer space ImVec2 clip_off = draw_data->DisplayPos; @@ -258,42 +258,38 @@ const D3D11_RECT r = { (LONG)clip_min.x, (LONG)clip_min.y, (LONG)clip_max.x, (LO ctx->RSSetScissorRects(1, &r); ``` -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -# Q&A: Usage +## Usage -## Q: About the ID Stack system... +### The ID Stack system -**USING THE SAME LABEL+ID IS THE MOST COMMON USER MISTAKE!** -
**USING AN EMPTY LABEL IS THE SAME AS USING THE SAME LABEL AS YOUR PARENT WIDGET!** -
Read the questions in this section for a more general understand of how labels and ID works in Dear ImGui. +> **The #1 user mistake is reusing the same label/ID.** +> An empty label behaves the same as reusing the parent widget's label. -TL;DR; -- Widgets labels are also used to compute Widgets unique identifiers. -- Unique identifiers are hashes of the label + of the parent scope (e.g. parent window or parent tree node labels). -- You can use `PushID()` to append to the identifier without making it visible. -- You can use `"##something"` in a label to append to the identifier without making it visible. -- You can use `"###something"` in a label to make the identifier ignore the visible part. +**TL;DR** +- Widget labels also compute the widget's unique ID. +- IDs are a hash of the label plus the enclosing scope (parent window, tree node, etc.). +- `PushID()` appends to the ID stack without affecting visible text. +- `"##something"` in a label appends to the ID without showing. +- `"###something"` makes the ID ignore the visible part of the label entirely. -
-
+**Common mistake vs. fixes:**
+```cpp
ImGui::Begin("Incorrect!");
ImGui::DragFloat2("My value", &objects[0]->pos.x);
-ImGui::DragFloat2("My value", &objects[1]->pos.x);
-ImGui::DragFloat2("My value", &objects[2]->pos.x);
+ImGui::DragFloat2("My value", &objects[1]->pos.x); // ID collision!
+ImGui::DragFloat2("My value", &objects[2]->pos.x); // ID collision!
ImGui::End();
-
+
ImGui::Begin("Correct!");
ImGui::DragFloat2("My value", &objects[0]->pos.x);
ImGui::DragFloat2("My value##2", &objects[1]->pos.x);
ImGui::DragFloat2("My value##3", &objects[2]->pos.x);
ImGui::End();
-
+
ImGui::Begin("Also Correct!");
for (int n = 0; n < 3; n++)
{
@@ -302,628 +298,426 @@ for (int n = 0; n < 3; n++)
ImGui::PopID();
}
ImGui::End();
-
- |
-
-
-// Window label has animating FPS counter
-// Window ID stays the same = hash of "MyGame"
+```cpp
char buf[128];
sprintf(buf, "My game (%.1f FPS)###MyGame", io.Framerate);
-ImGui::Begin(buf);
-
-// Label changes between "Enable" and "Disable"
-// ID stays the same = hash of ("MyGame", "MyButton")
+ImGui::Begin(buf); // Window ID stays constant even as the title text animates
+
if (ImGui::Button(enabled ? "Disable###MyButton" : "Enable###MyButton", { -FLT_MIN, 0.0f }))
enabled = !enabled;
-
+
ImGui::End();
-
- |
-
-Unique IDs are implicitly built from the hash of multiple elements that identify the "path" to the UI element.** - -You can use `Demo>Tools>ID Stack Tool` or call `ImGui::ShowIDStackToolWindow()`. The tool display intermediate values leading to the creation of a unique ID, making things easier to debug and understand. - - - -- Unique ID are often derived from a string label and at minimum scoped within their host window: ```cpp Begin("MyWindow"); -Button("OK"); // Label = "OK", ID = hash of ("MyWindow", "OK") -Button("Cancel"); // Label = "Cancel", ID = hash of ("MyWindow", "Cancel") +Button("OK"); // ID = hash("MyWindow", "OK") +Button("Cancel"); // ID = hash("MyWindow", "Cancel") End(); ``` -- Other elements such as tree nodes, etc. also pushes to the ID stack: + +Nested scopes (tree nodes, etc.) extend the path: ```cpp Begin("MyWindow"); if (TreeNode("MyTreeNode")) { - Button("OK"); // Label = "OK", ID = hash of ("MyWindow", "MyTreeNode", "OK") + Button("OK"); // ID = hash("MyWindow", "MyTreeNode", "OK") TreePop(); } End(); ``` -- Two items labeled "OK" in different windows or different tree locations won't collide: + +Same label in different scopes doesn't collide: ```cpp -Begin("MyFirstWindow"); -Button("OK"); // Label = "OK", ID = hash of ("MyFirstWindow", "OK") -End(); -Begin("MyOtherWindow"); -Button("OK"); // Label = "OK", ID = hash of ("MyOtherWindow", "OK") -End(); +Begin("MyFirstWindow"); Button("OK"); End(); // hash("MyFirstWindow", "OK") +Begin("MyOtherWindow"); Button("OK"); End(); // hash("MyOtherWindow", "OK") ``` -- If you have a same ID twice in the same location, you'll have a conflict: +Same ID twice in the same scope **does** collide: ```cpp Begin("MyWindow"); Button("OK"); -Button("OK"); // ERROR: ID collision with the first button! Interacting with either button will trigger the first one. -Button(""); // ERROR: ID collision with Begin("MyWindow")! -End(); -``` -Fear not! This is easy to solve and there are many ways to solve it! - -- Solving ID conflict in a simple/local context: -When passing a label you can optionally specify extra ID information within the string itself. -Use "##" to pass a complement to the ID that won't be visible to the end-user. -This helps solve the simple collision cases when you know e.g. at compilation time which items -are going to be created: -```cpp -Begin("MyWindow"); -Button("Play"); // Label = "Play", ID = hash of ("MyWindow", "Play") -Button("Play##foo1"); // Label = "Play", ID = hash of ("MyWindow", "Play##foo1") // Different from other buttons -Button("Play##foo2"); // Label = "Play", ID = hash of ("MyWindow", "Play##foo2") // Different from other buttons -Button("##foo"); // Label = "", ID = hash of ("MyWindow", "##foo") // Different from window +Button("OK"); // ERROR: collides with the first button +Button(""); // ERROR: collides with Begin("MyWindow") End(); ``` -- Solving ID conflict in a more general manner: -Use `PushID()` / `PopID()` to create scopes and manipulate the ID stack, as to avoid ID conflicts -within the same window. This is the most convenient way of distinguishing ID when iterating and -creating many UI elements programmatically. -You can push a pointer, a string, or an integer value into the ID stack. -Remember that IDs are formed from the concatenation of _everything_ pushed into the ID stack. -At each level of the stack, we store the seed used for items at this level of the ID stack. +`PushID()` / `PopID()` accept a pointer, string, or integer, and can be stacked: ```cpp -Begin("Window"); -for (int i = 0; i < 100; i++) -{ - PushID(i); // Push i to the id tack - Button("Click"); // Label = "Click", ID = hash of ("Window", i, "Click") - PopID(); -} -for (int i = 0; i < 100; i++) -{ - MyObject* obj = Objects[i]; - PushID(obj); - Button("Click"); // Label = "Click", ID = hash of ("Window", obj pointer, "Click") - PopID(); -} -for (int i = 0; i < 100; i++) -{ - MyObject* obj = Objects[i]; - PushID(obj->Name); - Button("Click"); // Label = "Click", ID = hash of ("Window", obj->Name, "Click") - PopID(); -} -End(); -``` -- You can stack multiple prefixes into the ID stack: -```cpp -Button("Click"); // Label = "Click", ID = hash of (..., "Click") +Button("Click"); // ID = hash(..., "Click") PushID("node"); - Button("Click"); // Label = "Click", ID = hash of (..., "node", "Click") + Button("Click"); // ID = hash(..., "node", "Click") PushID(my_ptr); - Button("Click"); // Label = "Click", ID = hash of (..., "node", my_ptr, "Click") + Button("Click"); // ID = hash(..., "node", my_ptr, "Click") PopID(); PopID(); ``` -- Tree nodes implicitly create a scope for you by calling `PushID()`: + +Tree nodes push their own scope implicitly: ```cpp -Button("Click"); // Label = "Click", ID = hash of (..., "Click") -if (TreeNode("node")) // <-- this function call will do a PushID() for you (unless instructed not to, with a special flag) +Button("Click"); // ID = hash(..., "Click") +if (TreeNode("node")) // implicitly calls PushID(), unless told not to { - Button("Click"); // Label = "Click", ID = hash of (..., "node", "Click") + Button("Click"); // ID = hash(..., "node", "Click") TreePop(); } ``` -When working with trees, IDs are used to preserve the open/close state of each tree node. -Depending on your use cases you may want to use strings, indices, or pointers as ID. -- e.g. when following a single pointer that may change over time, using a static string as ID -will preserve your node open/closed state when the targeted object change. -- e.g. when displaying a list of objects, using indices or pointers as ID will preserve the -node open/closed state differently. See what makes more sense in your situation! +For tree open/close state specifically: a stable string ID preserves state when the tracked object changes; indices or pointers preserve state differently when iterating a list. Pick whichever fits your use case. -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: How can I display an image? -### Q: What are ImTextureID/ImTextureRef? +### How can I display an image? (ImTextureID / ImTexturRef) -**Short explanation:** -- You may use functions such as `ImGui::Image()`, `ImGui::ImageButton()` or lower-level `ImDrawList::AddImage()` to emit draw calls that will use your own textures. -- To load and display your own textures, refer to [Image Loading and Displaying Examples](https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples) on the [Wiki](https://github.com/ocornut/imgui/wiki). -- Actual textures are identified in a way that is up to the user/engine. Those identifiers are stored and passed as an opaque ImTextureID value. -- By default ImTextureID can store up to 64-bits. You may `#define` it to a custom type/structure if you need. -- Loading image files from the disk and turning them into a texture is not within the scope of Dear ImGui (for a good reason), but the examples linked above may be useful references. +**Short version** +- Use `ImGui::Image()`, `ImGui::ImageButton()`, or the lower-level `ImDrawList::AddImage()` to draw your own textures. +- See [Image Loading and Displaying Examples](https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples) for loading/display recipes. +- Textures are identified by an opaque `ImTextureID` value, meaning is entirely up to you/your engine. +- Default `ImTextureID` holds up to 64 bits; redefine it via `#define` for a custom type if needed. +- Loading images from disk into a texture is deliberately outside Dear ImGui's scope (see the linked examples for that). -**Details:** +**ImTextureID vs. ImTextureRef** -1.92 introduced `ImTextureRef` in June 2025. -- All drawing functions using `ImTextureID` were changed to use `ImTextureRef`. -- You can trivially create a `ImTextureRef` from a `ImTextureID`. -- **If you use Image functions with textures that you have loaded/created yourself, you will mostly likely only ever store/manipulate `ImTextureID` and then pass them as `ImTextureRef`.** -- You only NEED to manipulate `ImTextureRef` when dealing with textures managed by the backend itself, aka mainly the atlas texture for now. -- We intentionally do not provide an implicit `ImTextureRef` -> `ImTextureID` cast operator because it is technically lossy to convert ImTextureRef to ImTextureID before rendering. +`ImTextureRef` (added June 2025, in 1.92) is now what all drawing functions accept and what's stored in `ImDrawCmd`. + +- If you manage your own textures, you'll mostly only ever touch `ImTextureID`, trivially convertible to `ImTextureRef`. +- You only need `ImTextureRef` directly when dealing with backend-managed textures (mainly the font atlas). +- There's intentionally no implicit `ImTextureRef → ImTextureID` cast, since that conversion is lossy before rendering. -**ImTextureID = backend specific, low-level identifier for a texture uploaded in GPU/graphics system.** ```cpp +// ImTextureID — low-level, backend-specific texture identifier #ifndef ImTextureID -typedef ImU64 ImTextureID; // Default: store up to 64-bits (any pointer or integer). A majority of backends are ok with that. +typedef ImU64 ImTextureID; // default: 64 bits, enough for a pointer or integer #endif ``` -- When a Rendered Backend creates a texture, it store its native identifier into a ImTextureID value (e.g. Used by DX11 backend to a `ID3D11ShaderResourceView*`; Used by OpenGL backends to store `GLuint`; Used by SDLGPU backend to store a `SDL_GPUTextureSamplerBinding*`, etc.). -- User may submit their own textures to e.g. `ImGui::Image()` function by passing this value. -- During the rendering loop, the Renderer Backend retrieve the ImTextureID, which stored inside a ImTextureRef, which is stored inside ImDrawCmd. -- Compile-time type configuration: - - To use something other than a 64-bit value: add '#define ImTextureID MyTextureType*' in your imconfig.h file. - - This can be whatever to you want it to be! read the FAQ entry about textures for details. - - You may decide to store a higher-level structure containing texture, sampler, shader etc. with various constructors if you like. You will need to implement ==/!= operators. +Per-backend meaning of `ImTextureID`: +- OpenGL: `GLuint` +- DirectX9: `LPDIRECT3DTEXTURE9` +- DirectX11: `ID3D11ShaderResourceView*` +- DirectX12: `D3D12_GPU_DESCRIPTOR_HANDLE` + +To use something other than a 64-bit value: `#define ImTextureID MyTextureType*` in `imconfig.h`. You can store a richer struct (texture + sampler + shader, etc.) as long as you implement `==`/`!=`. -**ImTextureRef = higher-level identifier for a texture.** ```cpp -// Store a ImTextureID _or_ a ImTextureData*. +// ImTextureRef — higher-level identifier, valid even before GPU upload struct ImTextureRef { ImTextureRef() { _TexData = NULL; _TexID = ImTextureID_Invalid; } ImTextureRef(ImTextureID tex_id) { _TexData = NULL; _TexID = tex_id; } inline ImTextureID GetTexID() const { return _TexData ? _TexData->TexID : _TexID; } - // Members (either are set, never both!) - ImTextureData* _TexData; // A texture, generally owned by a ImFontAtlas. Will convert to ImTextureID during render loop, after texture has been uploaded. - ImTextureID _TexID; // _OR_ Low-level backend texture identifier, if already uploaded or created by user/app. Generally provided to e.g. ImGui::Image() calls. + ImTextureData* _TexData; // Owned by ImFontAtlas; resolves to ImTextureID after upload. + ImTextureID _TexID; // _OR_ Already-created backend texture id, passed to e.g. ImGui::Image(). }; ``` -- The identifier is valid even before the texture has been uploaded to the GPU/graphics system. -- This is what gets passed to functions such as `ImGui::Image()`, `ImDrawList::AddImage()`. -- This is what gets stored in draw commands (`ImDrawCmd`) to identify a texture during rendering. - - When a texture is created by user code (e.g. custom images), we directly store the low-level `ImTextureID`. - - Because of this, when displaying your own texture you are likely to ever only manage ImTextureID values on your side. - - When a texture is created by the backend, we store a `ImTextureData*` which becomes an indirection to extract the `ImTextureID` value during rendering, after texture upload has happened. - - To create a `ImTextureRef` from a `ImTextureData*` you can use `ImTextureData::GetTexRef()`. - We intentionally do not provide an `ImTextureRef` constructor for this: we don't expect this to be frequently useful to the end-user, and it would be erroneously called by many legacy code. - - There is no constructor to create a `ImTextureRef` from a `ImTextureData*` as we don't expect this to be useful to the end-user, and it would be erroneously called by many legacy code. - - If you want to bind the current atlas when using custom rectangles, you can use `io.Fonts->TexRef`. - - Binding generators for languages such as C (which don't have constructors), should provide a helper, e.g. `inline ImTextureRef ImTextureRefFromID(ImTextureID tex_id) { ImTextureRef tex_ref = { ._TexData = NULL, .TexID = tex_id }; return tex_ref; }` +- User-created textures store `ImTextureID` directly. +- Backend-created textures (mainly the atlas) store a `ImTextureData*`, resolved to `ImTextureID` after upload — use `ImTextureData::GetTexRef()` to build the ref. +- For custom rectangles on the current atlas, use `io.Fonts->TexRef`. +- Binding authors for languages without constructors (e.g. C) should provide a helper like: + ```c + inline ImTextureRef ImTextureRefFromID(ImTextureID tex_id) { ImTextureRef tex_ref = { ._TexData = NULL, .TexID = tex_id }; return tex_ref; } + ``` -**Please read documentations or tutorials on your graphics API to understand how to display textures on the screen before moving onward.** +**Longer explanation** -Long explanation: -- Dear ImGui's job is to create "meshes", defined in a renderer-agnostic format made of draw commands and vertices. At the end of the frame, those meshes (ImDrawList) will be displayed by your rendering function. They are made up of textured polygons and the code to render them is generally fairly short (a few dozen lines). In the examples/ folder, we provide functions for popular graphics APIs (OpenGL, DirectX, etc.). -- Each rendering function decides on a data type to represent "textures". The concept of what is a "texture" is entirely tied to your underlying engine/graphics API. -We carry the information to identify a "texture" in the ImTextureID type, which itself tends to be stored inside a ImTextureRef. -ImTextureID default to ImU64 aka 8 bytes worth of data: just enough to store one pointer or integer of your choice. -Dear ImGui doesn't know or understand what you are storing in ImTextureID, it merely passes values until they reach your rendering function. -- In the [examples/](https://github.com/ocornut/imgui/tree/master/examples) backends, for each graphics API we decided on a type that is likely to be a good representation for specifying an image from the end-user perspective. This is what the _examples_ rendering functions are using: -```cpp -OpenGL: -- ImTextureID should contains 'GLuint' (GL texture identifier). -- See ImGui_ImplOpenGL3_RenderDrawData() function in imgui_impl_opengl3.cpp -``` -```cpp -DirectX9: -- ImTextureID should contain a 'LPDIRECT3DTEXTURE9' (pointer). -- See ImGui_ImplDX9_RenderDrawData() function in imgui_impl_dx9.cpp -``` -```cpp -DirectX11: -- ImTextureID should contain a 'ID3D11ShaderResourceView*' (pointer) -- See ImGui_ImplDX11_RenderDrawData() function in imgui_impl_dx11.cpp -``` -```cpp -DirectX12: -- ImTextureID should contain a 'D3D12_GPU_DESCRIPTOR_HANDLE' (always 64-bits) -- See ImGui_ImplDX12_RenderDrawData() function in imgui_impl_dx12.cpp -``` -For example, in the OpenGL example backend we store raw OpenGL texture identifier (GLuint) inside ImTextureID. -Whereas in the DirectX11 example backend we store a pointer to ID3D11ShaderResourceView inside ImTextureID, which is a higher-level structure tying together both the texture and information about its format and how to read it. +Dear ImGui produces renderer-agnostic meshes (`ImDrawList`) made of textured polygons; your render function displays them at end of frame. Each backend picks a representation for "texture" that suits its API — the code to do so is typically a few dozen lines (see [examples/](https://github.com/ocornut/imgui/tree/master/examples)). -- If you have a custom engine built over e.g. OpenGL, instead of passing GLuint around you may decide to use a high-level data type to carry information about the texture as well as how to display it (shaders, etc.). The decision of what to use as ImTextureID can always be made better by knowing how your codebase is designed. If your engine has high-level data types for "textures" and "material" then you may want to use them. -If you are starting with OpenGL or DirectX or Vulkan and haven't built much of a rendering engine over them, keeping the default ImTextureID representation suggested by the example backends is probably the best choice. -(Advanced users may also decide to keep a low-level type in ImTextureID, use ImDrawList callback and pass information to their renderer) +If you have a custom engine, you can store something richer than a raw handle in `ImTextureID` — whatever fits your codebase's existing texture/material types. If you're new to OpenGL/DirectX/Vulkan, stick with the example backends' default choice. -User code may do: ```cpp -// Cast our texture type to ImTextureID +// User code: MyTexture* texture = g_CoffeeTableTexture; ImGui::Image((ImTextureID)(intptr_t)texture, ImVec2(texture->Width, texture->Height)); -``` -The renderer function called after ImGui::Render() will receive that same value that the user code passed: -```cpp -// Cast ImTextureID stored in the draw command as our texture type + +// Later, in your render function: MyTexture* texture = (MyTexture*)(intptr_t)pcmd->GetTexID(); MyEngineBindTexture2D(texture); ``` -Once you understand this design, you will understand that loading image files and turning them into displayable textures is not within the scope of Dear ImGui. -This is by design and is a good thing because it means your code has full control over your data types and how you display them. -If you want to display an image file (e.g. PNG file) on the screen, please refer to documentation and tutorials for the graphics API you are using. -Refer to [Image Loading and Displaying Examples](https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples) on the [Wiki](https://github.com/ocornut/imgui/wiki) to find simplified examples for loading textures with OpenGL, DirectX9 and DirectX11. - -C/C++ tip: a u64 is 8 bytes. You may safely store any pointer or integer into it by casting your value to ImTextureID, and vice-versa. -Because both end-points (user code and rendering function) are under your control, you know exactly what is stored inside the ImTextureID. -Here are some examples: +Casting examples: ```cpp GLuint my_tex = XXX; -ImTextureID my_imtexid; -my_imtexid = (ImTextureID)(intptr_t)my_tex; // cast a GLuint into a ImTextureID (we don't take its address! we just copy the address) -my_tex = (GLuint)(intptr_t)my_imtexid; // cast a ImTextureID into a GLuint +ImTextureID my_imtexid = (ImTextureID)(intptr_t)my_tex; +my_tex = (GLuint)(intptr_t)my_imtexid; ID3D11ShaderResourceView* my_dx11_srv = XXX; -ImTextureID my_imtexid; -my_imtexid = (ImTextureID)(intptr_t)my_dx11_srv; // cast a ID3D11ShaderResourceView* into an opaque ImTextureID -my_dx11_srv = (ID3D11ShaderResourceView*)(intptr_t)_my_imtexid; // cast a ImTextureID into a ID3D11ShaderResourceView* +ImTextureID my_imtexid = (ImTextureID)(intptr_t)my_dx11_srv; +my_dx11_srv = (ID3D11ShaderResourceView*)(intptr_t)my_imtexid; ``` -Finally, you may call `ImGui::ShowMetricsWindow()` to explore/visualize/understand how the ImDrawList are generated. -##### [Return to Index](#index) +Use `ImGui::ShowMetricsWindow()` to visualize how `ImDrawList`s are generated. For loading actual image files, see [Image Loading and Displaying Examples](https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples). + +[↑ Back to top](#table-of-contents) --- -### Q: How can I use maths operators with ImVec2? +### Math operators with ImVec2 -We do not export maths operators by default in imgui.h in order to not conflict with the use of your own maths types and maths operators. As a convenience, you may use `#define IMGUI_DEFINE_MATH_OPERATORS` + `#include "imgui.h"` to access our basic maths operators. +Not exported by default (to avoid clashing with your own math library). Opt in with: +```cpp +#define IMGUI_DEFINE_MATH_OPERATORS +#include "imgui.h" +``` -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: How can I use my own maths types instead of ImVec2/ImVec4? +### Using your own math types -You can setup your [imconfig.h](https://github.com/ocornut/imgui/blob/master/imconfig.h) file with `IM_VEC2_CLASS_EXTRA`/`IM_VEC4_CLASS_EXTRA` macros to add implicit type conversions to our own maths types. -This way you will be able to use your own types everywhere, e.g. passing `MyVector2` or `glm::vec2` to ImGui functions instead of `ImVec2`. +Set `IM_VEC2_CLASS_EXTRA` / `IM_VEC4_CLASS_EXTRA` in [imconfig.h](https://github.com/ocornut/imgui/blob/master/imconfig.h) to add implicit conversions to your own types (e.g. `glm::vec2`), so you can pass them directly wherever `ImVec2`/`ImVec4` is expected. -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -### Q: How can I interact with standard C++ types (such as std::string and std::vector)? -- Being highly portable (backends/bindings for several languages, frameworks, programming styles, obscure or older platforms/compilers), and aiming for compatibility & performance suitable for every modern real-time game engine, Dear ImGui does not use any of std C++ types. We use raw types (e.g. char* instead of std::string) because they adapt to more use cases. -- To use ImGui::InputText() with a std::string or any resizable string class, see [misc/cpp/imgui_stdlib.h](https://github.com/ocornut/imgui/blob/master/misc/cpp/imgui_stdlib.h). -- To use combo boxes and list boxes with `std::vector` or any other data structure: the `BeginCombo()/EndCombo()` API -lets you iterate and submit items yourself, so does the `ListBoxHeader()/ListBoxFooter()` API. -Prefer using them over the old and awkward `Combo()/ListBox()` api. -- Generally for most high-level types you should be able to access the underlying data type. -You may write your own one-liner wrappers to facilitate user code (tip: add new functions in ImGui:: namespace from your code). -- Dear ImGui applications often need to make intensive use of strings. It is expected that many of the strings you will pass -to the API are raw literals (free in C/C++) or allocated in a manner that won't incur a large cost on your application. -Please bear in mind that using `std::string` on applications with a large amount of UI may incur unsatisfactory performances. -Modern implementations of `std::string` often include small-string optimization (which is often a local buffer) but those -are not configurable and not the same across implementations. -- If you are finding your UI traversal cost to be too large, make sure your string usage is not leading to an excessive amount -of heap allocations. Consider using literals, statically sized buffers, and your own helper functions. A common pattern -is that you will need to build lots of strings on the fly, and their maximum length can be easily scoped ahead. -One possible implementation of a helper to facilitate printf-style building of strings: https://github.com/ocornut/Str -This is a small helper where you can instance strings with configurable local buffers length. Many game engines will -provide similar or better string helpers. +### Interacting with std::string / std::vector -##### [Return to Index](#index) +- Dear ImGui avoids std C++ types entirely (uses `char*`, not `std::string`) to stay portable across languages, frameworks, and older/obscure platforms. +- For `InputText()` with `std::string` or similar, see [misc/cpp/imgui_stdlib.h](https://github.com/ocornut/imgui/blob/master/misc/cpp/imgui_stdlib.h). +- For combo/list boxes over `std::vector` or custom containers, use `BeginCombo()/EndCombo()` (or the list-box equivalent) to iterate and submit items yourself, rather than the older `Combo()`/`ListBox()` API. +- For most high-level types you can just reach the underlying raw data, or write small one-line wrappers in the `ImGui::` namespace. +- Heavy `std::string` use in large UIs can hurt performance — small-string optimization helps but isn't standardized. Prefer literals, static buffers, or a lightweight string helper (e.g. [ocornut/Str](https://github.com/ocornut/Str)) if UI traversal cost becomes an issue. + +[↑ Back to top](#table-of-contents) --- -### Q: How can I display custom shapes? (using low-level ImDrawList API) +### Displaying custom shapes (ImDrawList) -- You can use the low-level `ImDrawList` api to render shapes within a window. ```cpp ImGui::Begin("My shapes"); ImDrawList* draw_list = ImGui::GetWindowDrawList(); - -// Get the current ImGui cursor position ImVec2 p = ImGui::GetCursorScreenPos(); -// Draw a red circle draw_list->AddCircleFilled(ImVec2(p.x + 50, p.y + 50), 30.0f, IM_COL32(255, 0, 0, 255)); - -// Draw a 3 pixel thick yellow line draw_list->AddLine(ImVec2(p.x, p.y), ImVec2(p.x + 100.0f, p.y + 100.0f), IM_COL32(255, 255, 0, 255), 3.0f); -// Advance the ImGui cursor to claim space in the window (otherwise the window will appear small and needs to be resized) -ImGui::Dummy(ImVec2(200, 200)); +ImGui::Dummy(ImVec2(200, 200)); // claim layout space so the window isn't tiny ImGui::End(); ``` - -- Refer to "Demo > Examples > Custom Rendering" in the demo window and read the code of `ShowExampleAppCustomRendering()` in `imgui_demo.cpp` from more examples. -- To generate colors: you can use the macro `IM_COL32(255,255,255,255)` to generate them at compile time, or use `ImGui::GetColorU32(IM_COL32(255,255,255,255))` or `ImGui::GetColorU32(ImVec4(1.0f,1.0f,1.0f,1.0f))` to generate a color that is multiplied by the current value of `style.Alpha`. -- Math operators: if you have setup `IM_VEC2_CLASS_EXTRA` in `imconfig.h` to bind your own math types, you can use your own math types and their natural operators instead of ImVec2. ImVec2 by default doesn't export any math operators in the public API. You may use `#define IMGUI_DEFINE_MATH_OPERATORS` `#include "imgui.h"` to use our math operators, but instead prefer using your own math library and set it up in `imconfig.h`. -- You can use `ImGui::GetBackgroundDrawList()` or `ImGui::GetForegroundDrawList()` to access draw lists which will be displayed behind and over every other Dear ImGui window (one bg/fg drawlist per viewport). This is very convenient if you need to quickly display something on the screen that is not associated with a Dear ImGui window. -- You can also create your own empty window and draw inside it. Call Begin() with the NoBackground | NoDecoration | NoSavedSettings | NoInputs flags (The `ImGuiWindowFlags_NoDecoration` flag itself is a shortcut for NoTitleBar | NoResize | NoScrollbar | NoCollapse). Then you can retrieve the ImDrawList* via `GetWindowDrawList()` and draw to it in any way you like. -- You can create your own ImDrawList instance. You'll need to initialize them with `ImGui::GetDrawListSharedData()`, or create your own instancing `ImDrawListSharedData`, and then call your renderer function with your own ImDrawList or ImDrawData data. -- Looking for fun? The [ImDrawList coding party 2020](https://github.com/ocornut/imgui/issues/3606) thread is full of "don't do this at home" extreme uses of the ImDrawList API. +- See "Demo > Examples > Custom Rendering" (`ShowExampleAppCustomRendering()` in `imgui_demo.cpp`) for more. +- Build colors with `IM_COL32(r,g,b,a)` (compile-time), or `ImGui::GetColorU32(...)` to respect `style.Alpha`. +- If you've set up `IM_VEC2_CLASS_EXTRA`, use your own math library's operators instead of `IMGUI_DEFINE_MATH_OPERATORS`. +- `ImGui::GetBackgroundDrawList()` / `GetForegroundDrawList()` draw behind/over every window (per viewport) — handy for anything not tied to a specific window. +- You can also create a borderless window (`NoBackground | NoDecoration | NoSavedSettings | NoInputs`) purely as a drawing surface via its `GetWindowDrawList()`. +- Or build a fully independent `ImDrawList` via `ImGui::GetDrawListSharedData()` and your own renderer call. +- For inspiration (and cautionary tales), see the [ImDrawList coding party 2020](https://github.com/ocornut/imgui/issues/3606) thread. -##### [Return to Index](#index) +[↑ Back to top](#table-of-contents) --- -# Q&A: Fonts, Text +## Fonts & Text -### Q: How should I handle DPI in my application? +### Handling DPI -Since 1.92 (June 2025) fonts may be dynamically used at any size. +Since 1.92 (June 2025), fonts can be used dynamically at any size. **Scaling fonts** +```cpp +style.FontSizeBase = 20.0f; // default size +style.FontScaleDpi = 2.0f; // scale all fonts -Select default size: -```cpp -style.FontSizeBase = 20.0f; -``` -Scale all fonts: -```cpp -style.FontScaleDpi = 2.0f; +ImGui::PushFont(NULL, 42.0f); // size only, multiplied by FontScaleDpi +ImGui::PushFont(new_font, 42.0f); // font + size ``` -To change font size: +Docking branch / multi-viewport: ```cpp -ImGui::PushFont(NULL, 42.0f); // This will be multiplied by style.FontScaleDpi -``` -To change font and font size: -```cpp -ImGui::PushFont(new_font, 42.0f); +io.ConfigDpiScaleFonts = true; // auto-update style.FontScaleDpi on monitor DPI change (fonts only, not padding/spacing — yet) +io.ConfigDpiScaleViewports = true; // scale ImGui + platform windows on monitor DPI change ``` -In `docking` branch or with multi-viewports: +**Scaling style (padding, spacing, thickness)** + +Still evolving. For single-viewport apps, call once: ```cpp -io.ConfigDpiScaleFonts = true; // (Docking branch only) Automatically overwrite style.FontScaleDpi in Begin() when Monitor DPI changes. This will scale fonts but _NOT_ scale sizes/padding for now. -io.ConfigDpiScaleViewports = true; // (Docking branch only) Scale Dear ImGui and Platform Windows when Monitor DPI changes. +style.ScaleAllSizes(factor); ``` +To change the factor later, reset the style and call again with the new value. -**Scaling style** (paddings, spacings, thicknesses) +Prefer expressing sizes as multiples of reference values (`ImGui::GetFontSize()`, `ImGui::GetFrameHeight()`) rather than hardcoded constants — e.g. `30 * ImGui::GetFontSize()` instead of a literal `500`. More standardized reference values are planned for future 1.92.x releases. -This is still massively work in progress, expect turbulence. -Style values are currently not easily scalable dynamically. -For single viewport application you can call once: -```cpp -style.ScaleAllSizes(factor); // call once! -``` -If you need to change the scaling factor, it is currently most practical to reset the style and call this again with a new value. +The multi-monitor, multi-DPI case (docking branch, viewports spanning monitors with different scales) doesn't yet have a fully satisfying solution for `ImGuiStyle`, though fonts themselves scale cleanly. -Your UI code should avoid using hardcoded constants for size and positioning. Prefer to express values as multiple of reference values such as `ImGui::GetFontSize()` or `ImGui::GetFrameHeight()`. So e.g. instead of seeing a hardcoded height of 500 for a given item/window, you may want to use `30*ImGui::GetFontSize()` instead. +**Windows-specific:** you must declare DPI awareness or Windows will blur your UI by scaling the whole window. +- SDL2: pass `SDL_WINDOW_ALLOW_HIGHDPI` to `SDL_CreateWindow()` + call `::SetProcessDPIAware()` +- SDL3: pass `SDL_WINDOW_HIGH_PIXEL_DENSITY` to `SDL_CreateWindow()` +- GLFW: automatic +- Other Win32 projects: use `ImGui_ImplWin32_EnableDpiAwareness()`, or set `