fastplotlib: GPU plotting across notebooks and desktop windows

fastplotlib's plotting scope and intended users

fastplotlib addresses the need for interactive exploration of large or rapidly changing data without building a separate rendering and event-handling stack for every project. Its documented uses include rapid prototyping, algorithm design, machine-learning model exploration, and real-time acquisition systems such as scientific cameras. The intended user is a Python developer or scientist who already has data to plot and needs an expressive API rather than a static figure generator.

The rendering stack is specific. fastplotlib is built on pygfx and uses WGPU, with access to Vulkan, DirectX 12, or Metal through that layer. The README describes GPU-accelerated visualization and rapid rendering of large-scale data, but it does not provide controlled performance measurements. Accordingly, the architecture establishes the route for accelerated plotting, while the repository documentation does not justify assumptions about latency, frame rate, or dataset-size limits.

The same plotting code is intended to work in Jupyter Lab and desktop applications based on Qt, PySide, glfw, or wxPython. This portability comes from separating visualization code from the selected frontend rather than maintaining a different API for each environment. It is useful for teaching, research prototypes, and applications that must move between notebooks and a windowed interface. It does not replace projects whose main requirement is a mature, fixed API for publication graphics or static image export.

pygfx, WGPU, and the fastplotlib rendering path

The repository layout and project metadata make the implementation path fairly direct. Python plotting code enters fastplotlib, fastplotlib delegates rendering work to pygfx, and pygfx uses WGPU for graphics operations. The declared core dependencies are `numpy>=2.1.0`, `pygfx==0.17.0`, `wgpu`, and `cmap>=0.1.3`. Pinning pygfx exactly is an important adoption detail because fastplotlib is coupled to a particular renderer API rather than an unconstrained renderer range.

WGPU acts as the graphics abstraction beneath the backend choices. The README names Vulkan, DX12, and Metal, and also points to the WGPU documentation for cloud-computing requirements. fastplotlib can therefore run across Linux, Windows, and Mac OS X only when the host has a compatible graphics stack and the applicable WGPU backend can operate there. The library is not independent of the operating system's graphics configuration.

The supported frontend list includes Jupyter Lab through `jupyter_rfb`, desktop interfaces through PyQt and PySide, plus `glfw` and wxPython. Optional extras control parts of that stack. The `notebook` extra installs Jupyter Lab and related components, while the `imgui` extra installs the WGPU imgui integration and a bounded `imgui-bundle` version. Based on `pyproject.toml`, the imgui pin exists because a newer bundle version removed `ImDrawData.cmd_lists_count`, which the released WGPU imgui backend still uses. That compatibility constraint should be checked during upgrades.

This architecture favors interactive renderer-backed applications over dependency-light static plotting. It also makes driver and adapter behavior part of deployment, rather than something the Python package can handle entirely on its own.

Installing fastplotlib for notebooks or desktop GUIs

The README recommends the imgui installation when interactive controls are wanted. Without Jupyter support, install a frontend such as glfw, PyQt6, or PySide6 separately. The project itself requires Python 3.11 or newer according to `pyproject.toml`.

Use this command for a desktop-oriented installation with imgui support. It installs the latest published fastplotlib package from the configuration named in the README:

pip install -U "fastplotlib[imgui]"

For Jupyter Lab together with imgui support, use:

pip install -U "fastplotlib[notebook,imgui]"

The minimal package does not include imgui. The README says to install the desired GUI library separately in this case:

pip install fastplotlib

For notebook support without imgui, select the notebook extra:

pip install -U "fastplotlib[notebook]"

A successful package installation does not confirm that the graphics backend is available. The README says GPUs from 2017 or later should generally be fine, while explicitly qualifying that requirement by visualization complexity and object count. It also warns that the pip version can be outdated because fastplotlib and pygfx evolve quickly. If current unreleased renderer behavior is required, the repository provides a developer installation path.

After cloning, install every extra in editable mode and install pygfx from its `main` branch. The first command establishes the local checkout; the second follows the renderer branch used by the project:

git clone https://github.com/fastplotlib/fastplotlib.git
cd fastplotlib

pip install -e ".[notebook,docs,tests,imgui]"

pip install git+https://github.com/pygfx/pygfx.git@main

The README requires `git-lfs` for the developer setup and points to `CONTRIBUTING.md` for further instructions. This route is suitable when the latest features are specifically needed, but it also replaces released-version pinning with dependencies that can change independently.

Starting with the fastplotlib quickstart notebook

The clearest documented first use is the repository's `quickstart.ipynb` tutorial notebook. It is linked from the README as the recommended way to become familiar with the API. Because the README states that plotting code is identical across Jupyter Lab and desktop use with Qt, PySide, or glfw, a reader can learn the plotting calls in the notebook and apply the same calls in a desktop application.

There is an installation dependency to account for. The notebook extra includes `jupyterlab`, `jupyter-rfb>=0.5.1`, `ipywidgets>=8.0.0,<9`, `sidecar`, and `simplejpeg`. That matters because fastplotlib is not just a plotting library in this context. Jupyter Lab needs the remote framebuffer integration, while ipywidgets supplies the interactive controls expected by notebook-oriented examples.

The repository also groups examples by object and workflow, including controllers, events, global configuration, grid plots, heatmaps, images, lines, meshes, ndwidgets, Qt, scatter plots, and selection tools. Those directories provide more targeted starting points after the quickstart, but the README does not state that every example has identical dependencies or works in every supported frontend.

For conda-forge users, the README lists separate packages: `imgui-bundle` for imgui support, plus `jupyter-rfb` and `simplejpeg` for Jupyter Lab. It also identifies all three as available through conda-forge. A first-use check should therefore confirm that the intended frontend and optional controls are installed, rather than assuming that a plain fastplotlib package includes the complete notebook interface.

Alpha status, API changes, and upgrade boundaries

The largest limitation is stated by the project itself: fastplotlib is in the "late alpha stage." The README links a separate API-stability discussion and a roadmap. This status means adoption can require code and dependency review after upgrades, even when an installation completes without errors.

The package metadata sharpens that concern. `pyproject.toml` requires Python `>= 3.11`, so Python 3.10 and earlier are outside the declared range. It pins `pygfx==0.17.0`, while the README warns that the published fastplotlib package may be older than current source. The developer installation instead pulls pygfx from `main`. These are different operating models. Released installations offer a defined fastplotlib package and pinned pygfx release, whereas a developer checkout can combine local fastplotlib code with changing renderer code.

The `imgui` extra also contains a deliberate upper bound: `imgui-bundle<1.92.900`. Its comment ties that restriction to a WGPU imgui API incompatibility. An upgrade plan must account for both the fastplotlib release and the WGPU imgui backend, rather than upgrading Python packages independently and assuming compatibility.

The maintenance record shows recent project activity. The repository is not archived, its last push was on 2026-10-16, and `v0.7.0` was released on 2026-09-24. Those facts support continued development, but they do not establish API stability. The README's explicit late-alpha warning remains the more relevant decision constraint for production use.

GPU requirements and failure points in fastplotlib deployments

fastplotlib's platform coverage depends on the graphics environment, not only on Python package resolution. The README names WGPU backends such as Vulkan, DX12, and Metal. It sends readers to detailed GPU documentation for requirements and to the WGPU documentation for cloud-computing infrastructure. That division matters in servers and containers, where an application may have no conventional desktop adapter or may expose a backend differently from a workstation.

A headless or cloud deployment is therefore not guaranteed by the statement that Linux, Windows, and Mac OS X are supported. The frontend may work in one environment while adapter discovery, driver setup, or WGPU backend selection fails in another. The documentation does not define fallback rendering, a CPU-only mode, minimum VRAM, supported adapter matrix, or behavior when no compatible adapter is found.

The project is also a poor fit for workflows that require a fixed stable API without adaptation. Its stated uses emphasize interactive exploration and rapid prototyping. While that makes it relevant to algorithm design and acquisition systems, those same workflows may depend on stable event handlers, camera behavior, or widget APIs. The README does not document a formal compatibility guarantee for application code.

For static publication output or a narrowly fixed chart type, a simpler plotting library may be easier to maintain. fastplotlib is more relevant when the GUI, frequent redraws, interaction, and cross-frontend reuse are central requirements. The README does not provide an export-quality guarantee or benchmark establishing superiority for every plotting task.

fastplotlib versus a conventional Python plotting API

The practical alternative is a conventional CPU or GUI-backed plotting library whose API centers on producing figures and static or interactive chart objects. Such a library generally makes publication output, familiar axes semantics, and saved images its primary contract. fastplotlib instead places an interactive pygfx scene, WGPU adapter, and frontend integration at the center of the stack.

This difference affects deployment. A conventional library may require fewer graphics-specific driver decisions for simple chart generation. fastplotlib asks the adopter to account for WGPU, a supported backend, GPU drivers, and optional frontend packages. In exchange, its documented architecture targets interactive rendering and reuse of plotting code across Jupyter Lab, Qt, PySide, glfw, and wxPython.

The alternative should not be described as universally better. If a project only needs a static line chart, the extra graphics stack may add operational complexity without a clear benefit. If a project needs to inspect changing scientific or acquisition data through an interactive view, fastplotlib's renderer-oriented design is more closely aligned with the task.

Fastplotlib is also not a drop-in claim based on package branding. The README says the code is identical across its named frontends, but that portability does not erase API evolution or adapter requirements. A direct trial should use one representative dataset, one required interaction, and the intended production frontend before comparing adoption costs.

Apache-2.0 licensing and operational costs

fastplotlib is distributed under the Apache-2.0 license. That permits broad use, modification, and redistribution subject to the license's terms. The repository contains a `LICENSE` file, and the README characterizes the project as free and open source. This is a licensing classification, not legal advice; organizations should review the actual license text and their own obligations.

The practical upgrade cost extends beyond editing plotting calls. Python 3.11 is the minimum declared version. The core renderer is pinned to `pygfx==0.17.0`, and wgpu is included indirectly with a version constrained by pygfx. Notebook users also need packages in the `notebook` extra, including a capped ipywidgets range. Desktop users must select and install their own GUI library.

The imgui compatibility pin adds another checkpoint. Its stated purpose is to avoid a bundle version that removed `ImDrawData.cmd_lists_count` while the released WGPU imgui backend still expects that field. This illustrates why upgrading fastplotlib should include reviewing pygfx, wgpu, imgui-bundle, and the selected GUI frontend together.

The repository's current release and push history indicates recent maintenance, but upgrade planning should rely on the release notes and API-stability discussion rather than recent activity alone. The README does not document a formal long-term-support branch or a rollback procedure.

Editorial conclusion

fastplotlib fits engineers and scientists who need interactive plotting across Jupyter Lab, Qt, PySide, glfw, or wxPython and are comfortable following an API that the project still describes as unstable. It is a poor fit when a late alpha API, evolving dependencies, or an unconfirmed graphics driver is unacceptable. Check the installed fastplotlib version, required Python version, WGPU driver path, intended GUI framework, and relevant quickstart example before committing a production workflow to the library.

Frequently asked questions

Official sources

1. fastplotlib/fastplotlib on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases