-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Glossary
(work in progress)
Backends/Bindings: a piece of code that connects your OS/platform/windowing system, graphics API or programming language to Dear ImGui. In the examples/ folder we provide a bunch of imgui_impl_xxxx files which are backends for variety of platforms and graphics API. Many other third-party bindings exists.
Demo: the demo code in imgui_demo.cpp, which main entry point is the ImGui::ShowDemoWindow() function.
Docking: refer to the feature (currently available in the docking branch) where multiple windows can be combined with each others, creating tab bars, or layed out next to each others.
Draw command, ImDrawCmd: refer to one item within an ImDrawList. One draw command generally map to one draw call in the underlying graphics API. Some draw commands hold callbacks or special functions that don't necessarily map to an actual draw call in the graphics API.
Draw list, ImDrawList: refer to the low-level rendering API which you can use to submit shapes (such as rectangles, lines, circles or text elements). The ImGui API uses the ImDrawList API to draw elements. You can easily access the drawlist of the current ImGui window using ImGui::GetWindowDrawList() or access special drawlists such as ImGui::GetBackgroundDrawList() (drawn before every ImGui windows) or ImGui::GetForegroundDrawList() (drawn after every ImGui windows). A draw list is generally comprised of multi draw commands.
Examples: examples application in the sub-folders of examples/. An example application generally combines one or two backends + dear imgui code + a main.cpp file to form a running application.
Font atlas: a font atlas manage multiple fonts, which for performance reasons are generally rasterized and packed together into a single graphics texture. The font atlas also contains graphics data that are used by ImGui and ImDrawList.
Item: (same as Widget): a single ImGui element (e.g. a ImGui::Button() or ImGui::Text() call).
Navigation: refer to the subsystem in charge of allowing full control of the UI using Gamepad or Keyboard inputs. Initially Dear ImGui was mostly using mouse inputs and the "navigation" feature allowed directional navigation within a set of widgets.
Metrics: refer to the confusingly named Dear ImGui Metrics window, which main entry point is the ImGui::ShowMetricsWindow() function. The Metrics window exposes lots of internal information about the state of your Dear ImGui context. Using it can help you debug and understand many problems you may have with Dear ImGui. It may also help you better understand how Dear ImGui works.
Multi-Viewports: refer to the feature (currently available in the docking branch) where Dear ImGui window can easily be moved outside the boundaries of your main application window. The multi-viewports feature provides an interface to interact with bindings in order to create its own application windows to host the floating Dear ImGui windows.
Widgets: (same as Item): a single ImGui element (e.g. a ImGui::Button() or ImGui::Text() call).
Note: when talking about issues related to the multi-viewports feature, always try to remove ambiguity by specifying e.g. "Dear ImGui Window" vs "Platform Window".
Desktop: the area managed by the Operating System or Window Manager and covers all Platform Monitors.
Platform: refer to the low-level system used to interface with native windows: it could be an Operating System library (Win32) or a cross-platform library (such as SDL, GLFW, Allegro).
Platform Backend: refer to the piece of glue code used to have Dear ImGui interact with a given platform (e.g. imgui_impl_glfw.cpp file). This code typically creates and destroy Platform Windows associated to each Viewport, and setup the Platform Decorations based on Viewport flags.
Platform Decoration: refer to the frame and title bar managed and displayed by the Operating System or Widnow Manager.
Platform Monitor: refer to the representation of a monitor. On a modern OS, each monitor are associated to a non-overlapping set of coordinates (position, size), a work area (main area minus OS task bar) and a DPI scaling factor. Dear ImGui takes advantage of Platform Monitor knowledge for certain tasks (for exemple, tooltip windows gets clamped to fit within a single Platform Monitor and not straddle multiple monitors).
Platform Window: a window managed by the Operating System. This is typically associated to a framebuffer, a swap chain and the machinery to perform 3D rendering via some graphics API.
ImGui Decoration: refer to the frame and title bar managed and displayed by ImGui Windows.
ImGui Window: a window inside of Dear ImGui.
Host Viewport: A Host Viewport can contains multiple root ImGui Windows. Currently the Main Viewport is always a Host Viewport. In the future we would like to allow application to create 0, 1 or more Host Viewports. When a Host Viewport is moved, all the Dear ImGui Windows it contains gets moved along with it. By default, any ImGui Window overlapping a Host Viewport will be merged into it. Setting io.ConfigViewportsNoAutoMerge disable that behavior, so every ImGui Window will be hosted by their own unique Single-Window Viewport.
Single-Window Viewport, Owned Viewport: a Viewport owned by a single root ImGui Window. In the typical setup, dragging a ImGui Window outside the boundary of a Host Viewport will create a Single-Window Viewport for the purpose of allowing the ImGui Window to be displayed anywhere on the Desktop.
Main Viewport: Due to common usage and backward compatibility reason, the system currently enforce the creation of one Main Viewport which is typically the main application window created by the user application. The Main Viewport is also a Host Viewport. In most traditional application, the Main Viewport has Platform Decorations enabled when not maximized, and has Platform Decorations disabled when fullscreen. In the future we would like to completely remove the concept of a "Main Viewport" and instead allow the application to freely create 0, 1 or more Host Viewports. Most games applications will create 1 of them, whereas most desktopey applications are expected to create 0 of them. Using this scheme, an application creating no Host Viewport would have every ImGui Window showing inside an individual Platform Window with Platform Decorations disabled.
Viewport: The Dear ImGui representation of a Platform Window. When a Viewport is active, Dear ImGui creates a Platform Window for it. Whether the Platform Window has Platform Decorations enabled currently depends on the io.ConfigViewportsNoDecoration flag which gets turned into a ImGuiViewportFlags_NoDecoration for the Platform Backend to honor.