Dear PyGui: an immediate-mode GUI toolkit for Python scripts

What Dear PyGui is for, and who it is not for

Dear PyGui is a Python binding to Dear ImGui plus the ImPlot and imnodes extensions. The README describes it as "fundamentally different than other Python GUI frameworks" because it uses the immediate mode paradigm and the GPU. In practice that means you write a function that draws the interface, and the library calls it again on every frame. There is no widget object you keep and mutate later; state lives in your script, and the drawing code reads it.

That model fits a specific audience. If you already have a Python script that computes something, and you want sliders, checkboxes and a live plot on top of it, the immediate-mode loop is shorter than wiring callbacks into a retained tree. The README lists a node editor, graphs that display over one million datapoints at 60 fps, theme and resource inspection, runtime metrics and a debugger. Those are tool-building features. They point at engineers, researchers and internal-tool authors rather than at teams shipping a consumer desktop product with platform conventions.

The project is MIT licensed, written in C/C++, and the README states support for Windows 10 (DirectX 11), macOS (Metal) and Linux (OpenGL 3), with a Raspberry Pi 4 row carrying an older badge. It is not archived, and the last push was on 2026-05-02, the same date as the v2.3.1 release. The README also links a project status wiki page, which is the honest place to check what is planned rather than assumed.

How the immediate-mode loop and the C++ core fit together

The README's example is the whole architecture in miniature. You call dpg.create_context(), then dpg.create_viewport(), then dpg.setup_dearpygui(). Widgets are added inside a with dpg.window(...) block, which is a context manager that scopes where the following add_* calls land. Then dpg.show_viewport(), dpg.start_dearpygui() and dpg.destroy_context() bracket the run.

Underneath, the Python package is a thin layer over a compiled extension. setup.py defines a BinaryDistribution whose has_ext_modules returns True, and a DPGBuildCommand that shells out to CMake, so the wheel you install from PyPI contains compiled code rather than pure Python. The rendering goes through the platform graphics API named in the README table: DirectX 11 on Windows 10, Metal on macOS, OpenGL 3 on Linux. Dear ImGui draws the frame; ImPlot backs the plotting API; imnodes backs the node editor.

This explains both the speed claim and the constraints. Because the frame is rebuilt each pass, a slider's value is read by your callback or by dpg.get_value, and any change you make to script state shows up on the next frame without an explicit invalidate call. It also means anything expensive that you put inside the drawing path runs at frame rate. The README does not describe a virtualized or dirty-region rendering path, so the cost of your per-frame Python is yours to manage.

Installing Dear PyGui and running a first window

The README gives the install in two lines and one prerequisite: at least Python 3.8, 64-bit. There is no separate compiler step for users, because the published package is a binary distribution.

pip install dearpygui

The README also lists pip3 install dearpygui as the alternative spelling. After that, the README's own example is the shortest real program. It creates a window with a text label, a button wired to a callback, a text input and a float slider.

import dearpygui.dearpygui as dpg

def save_callback():
    print("Save Clicked")

dpg.create_context()
dpg.create_viewport()
dpg.setup_dearpygui()

with dpg.window(label="Example Window"):
    dpg.add_text("Hello world")
    dpg.add_button(label="Save", callback=save_callback)
    dpg.add_input_text(label="string")
    dpg.add_slider_float(label="float")

dpg.show_viewport()
dpg.start_dearpygui()
dpg.destroy_context()

Run it and a viewport opens with one window titled Example Window. Clicking Save prints Save Clicked to the terminal where you launched the script; the slider and text field hold their values for the lifetime of the loop. Note the order: the context and viewport are created before any widget, and destroy_context() comes after the loop returns, not before.

The faster way to see what the toolkit contains is the bundled demo, which the README says shows all of Dear PyGui's functionality.

python -m dearpygui.demo

The README notes that the demo's Python source lives in dearpygui/demo.py in the repository, so the demo doubles as a set of worked examples you can copy from.

Themes, tables and the node editor: what the search terms actually map to

People arrive looking for dearpygui themes, dearpygui table and the dearpygui node editor, and those are three different kinds of work. Themes are the cheapest to adopt: the README claims complete theme and style control, and the developer tools include theme and resource inspection, which suggests you can build a theme and inspect the result rather than guessing at color values.

Tables are a layout primitive, and the immediate-mode model shapes how you use them. Because the frame is redrawn, a table is rebuilt from your data each pass unless you deliberately cache. For a few hundred rows that is unremarkable. For a scrolling log with tens of thousands of entries, the per-frame cost sits in your Python loop, and the README offers no row-virtualization guarantee. The README's performance claim is specifically about graphs, not tables: over one million datapoints at 60 fps, with zoom and pan. Treat the plotting path and the table path as having different cost profiles.

The node editor comes from imnodes and is the feature that most distinguishes Dear PyGui from general-purpose Python GUI toolkits. If your application is a graph of connected nodes with typed links, the primitives exist. If your application is a settings dialog, the node editor is irrelevant weight you carry in the binary.

Where the immediate-mode choice becomes the wrong choice

The strongest limitation is the one the paradigm implies: there is no retained widget tree to reach into. If a background thread finishes a job and needs to update a progress bar, you do not hold a reference to that bar. You set a variable the drawing function reads, and the next frame picks it up. Code that assumes it can call a widget's setter from another thread has to be restructured around shared state plus the frame loop. The README mentions asynchronous function support under stability, but it does not document a general thread-safe widget mutation contract.

Accessibility and native platform integration are the second gap. Nothing in the README describes screen-reader support, native menu bars, system tray integration or platform file dialogs. Dear ImGui renders its own widgets into a GPU surface, so the operating system sees a window, not a tree of accessible controls. If your product must pass an accessibility audit or match the host platform's look, this is the wrong toolkit, and no amount of theming fixes the semantics layer.

The third constraint is deployment. The platform table maps each OS to one graphics API, and the Raspberry Pi 4 row shows an older version badge than the desktop rows. Machines with weak or unusual GPU drivers are the risk surface. The README does not document a software-rendering fallback, so a machine that cannot provide DirectX 11, Metal or OpenGL 3 is a machine where this may not start. That is a real constraint for virtualized desktops and remote sessions.

Dear PyGui versus Qt bindings, Tkinter and NiceGUI

The comparison that matters is against retained-mode toolkits. PyQt and PySide give you a widget object per control, a signal-and-slot connection model, native-looking widgets on each platform, and a mature accessibility story. You mutate a widget and it repaints. Dear PyGui inverts that: you redraw and the widgets reflect your state. For a plotting tool driven by a simulation loop, the inverted version is less code. For a form with fifty fields, validation and tab order, the retained version is less code, and the difference grows with the size of the form.

Tkinter ships with CPython, so it costs nothing to try and has no binary wheel to match against a GPU driver. It also looks dated and its plotting options are weaker. Dear PyGui trades that portability for GPU rendering and the ImPlot graph path.

Against a browser-based Python UI layer such as NiceGUI, the split is architectural rather than stylistic. NiceGUI renders in a browser, which means the UI runs anywhere a browser runs and you inherit HTML layout and accessibility, at the cost of running a web server and shipping a page. Dear PyGui is a native window with no server, which is what you want for a local analysis tool and what you do not want if the interface must be reachable from another machine over HTTP.

Upgrades, the MIT licence and what to check before you commit

Dear PyGui is MIT licensed. That is permissive: it allows use in closed-source products, and the repository's LICENSE file is the authoritative text. This is not legal advice, but the practical implication is that bundling the compiled extension into a commercial application does not by itself trigger a source-disclosure obligation, unlike a copyleft licence. Keep the copyright notice and licence text with your distribution as the licence requires.

Upgrade cost is shaped by the release history. The repository shows v2.2.0 on 2026-02-19, v2.3.0 on 2026-04-17 and v2.3.1 on 2026-05-02, so point releases arrive on a scale of weeks and the minor line moved twice in roughly two and a half months. Because the package is a binary distribution, an upgrade means a new wheel, and a new wheel means the graphics backend and its dependencies come along. Pin the version in your requirements and test the viewport on your oldest supported machine before rolling forward.

The README does not document a deprecation policy or a migration guide between minor versions, so treat a minor bump as something to verify rather than assume. The README's project status wiki page and the labelled feature and bug trackers are the places the project points to for what is in flight. If your application depends on a specific widget's behaviour, check that widget against the demo after each upgrade rather than reading the changelog alone.

Editorial conclusion

Adopt Dear PyGui for internal tools, plotting panels and node-based editors where the UI is redrawn from script state on every frame. Do not adopt it for apps that need native accessibility trees, platform dialogs or a retained widget hierarchy you mutate from background threads. Before committing, run python -m dearpygui.demo on every target machine, including the oldest GPU and driver combination you ship to, and check the platform table in the README against your OS.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes