pygfx: a modern graphics engine for Python, built on wgpu

One API over three graphics backends

The foundation choice is the thing to understand before anything else. Pygfx is built on wgpu, the Python binding to the wgpu graphics abstraction, and the documentation claims that this gives superior performance and reliability compared with OpenGL based solutions. What that means in practice is that the same code runs on Vulkan, Metal and DirectX 12, since the repository topics name all three. That matters for a scientific library because OpenGL has been a portability problem for years, and a renderer built on an abstraction that the driver vendors are themselves standardising on is a different bet from one built on an API that has been extended rather than revised. The design goal stated alongside it is simplicity and versatility, with a modular architecture so you can assemble graphical scenes for different applications, from scientific visualization to video game rendering. The dependency list is short and tells you where the weight sits, with the render canvas package and wgpu under the project umbrella, a linear algebra helper, numpy, freetype and a font shaper for text, a template engine and a colour space library.

Features that are unusual to find in a Python plotting library

The feature highlights are worth reading as a list of things that are hard elsewhere. There is SDF based text rendering, which is the technique that makes crisp text at any scale without a texture atlas per font size, and the documentation links an example specifically about text contrast, which is where SDF text usually falls apart. There is order independent transparency, the rendering technique for scenes with many overlapping transparent surfaces, where naive alpha blending produces the wrong result. There are lights, shadows and physically based rendering, so a surface can be described by how it behaves under light rather than by a hand-tuned highlight colour. There is an event system with built-in picking, meaning you can ask which object is under the cursor without writing your own ray casting. And there is texture and colour mapping supporting one, two and three dimensional data, which is the feature a scientist actually needs, because the data is often multidimensional and the mapping from value to colour is the point. The readme also points at a gallery of feature demos, each of which exists to show one of these in isolation.

The scene graph API, and the shape of a first program

The usage example is short enough to read as a first program, and it shows the object model. You create a mesh from a geometry and a surface, the geometry here being a box and the surface a Phong shader with a colour, you keep a rotation as a quaternion, and you define a function that runs before each render and multiplies the rotation into the mesh's local rotation. The show call takes the object and that callback:

import pygfx as gfx
import pylinalg as la

cube = gfx.Mesh(
    gfx.box_geometry(200, 200, 200),
    gfx.MeshPhongMaterial(color="#336699"),
)

rot = la.quat_from_euler((0, 0.01), order="XY")


def animate():
    cube.local.rotation = la.quat_mul(rot, cube.local.rotation)


if __name__ == "__main__":
    gfx.show(cube, before_render=animate)

The naming is worth noticing, because it tells you what the library considers primary. The transformation lives on the local property of the object, so a mesh has a local and a world transform, and the rotation is a quaternion rather than Euler angles, which avoids the gimbal problem. The callback is a before render hook, so animation is written as a plain function rather than as a subclass override. The readme notes that the example is designed against the main branch and may not work on the latest release from PyPI while the project is in beta, which is a caveat worth heeding rather than a detail to skip.

Installing needs a window and reasonably modern drivers

The install is a single command that pulls in the graphics library and a windowing library:

pip install -U pygfx glfw

The reason GLFW is in there is stated directly, and it is the detail most people miss. Pygfx needs some window to render to, and GLFW is one lightweight option, but there are others, and if you use a different wgpu compatible window manager or only render offscreen you may omit it. The alternatives named are a remote frame buffer library for rendering in Jupyter, and the Qt and wxPython toolkits. The platform requirements are in the wgpu documentation, and the summary is that you need modern enough graphics drivers and a reasonably recent pip. That is an honest constraint for a GPU library, and it is the point at which many scientific users will discover whether their cluster has a working driver stack at all. A development install is also documented, with a fork and clone, an editable install of the extras for development, docs and examples, and then the test suite.

The API can still change, so pin your version

The status section is the most important paragraph for anyone planning to depend on this. The project is working towards version 1.0, which means the API can change with each version, and the expectation stated in the documentation is to reach 1.0 near July 2026, at which point they start caring about backwards compatibility. Until then, the guidance is that you should probably pin the Pygfx version you are using and check the release notes when you update. That is the honest position of a pre-1.0 rendering library, and it is worth weighing against what you get. The release history shows the pace, with v0.17.0 from 2026-07-19, v0.16.0 from 2026-03-03 and v0.15.3 from 2025-12-15, so a version every couple of months with breaking changes possible in each. The last push was on 2026-10-16, so the branch is moving faster than the releases. The dependency metadata shows the same philosophy in the package constraints, with a comment explaining that upper bounds are set on some packages under the umbrella because they regularly break their API.

Testing across platforms, and the licence

The test suite is split into three parts, unit tests for the core, unit tests for the examples, and screenshot tests for the validation examples. The core and example tests run under pytest with the verbose flag, and the screenshot tests are the interesting case, because the documentation explains that they are difficult to guarantee across all development platforms and are best run on the continuous integration service where more predictable outcomes can be achieved, and they can be run on a local Linux machine by selecting the software rendering adapter with a named environment variable and a filtered test selection. The pytest configuration file also sets an environment variable that disables system fonts, to help ensure consistency across installations, which is the kind of detail that tells you the screenshot comparisons are sensitive to the host. The licence is BSD 2-Clause, and the readme spells out what that means in plain terms, including that the project is free and open source forever, that commercial use is allowed, that you can distribute it and make changes freely, and that you cannot hold the maintainers accountable for the results of using it.

Editorial conclusion

pygfx is a good fit for a scientific Python project that needs to show a lot of data quickly, or for a developer who wants a modern graphics pipeline without binding an OpenGL library, since the wgpu foundation means one API across Vulkan, Metal and DirectX 12. It is the wrong tool if you need the stability of a released API, because the project states it is working towards version 1.0 and that the API can change with each version until then, and it is the wrong tool if you want to render in a notebook without any setup, since something has to provide the window. It is also the wrong tool if you need the specific feature set of an existing OpenGL library. Before adopting it, pin the version you use and read the release notes when you update, as the documentation instructs, and confirm your graphics drivers are recent enough for wgpu. The project is BSD 2-Clause licensed, the last push was on 2026-10-16, and the current release is v0.17.0 from 2026-07-19.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. pygfx/pygfx on GitHub
4. README
5. Releases