📣 Help shape the future of VisPy 2.0 – ideas, feedback, and contributors welcome!

[rossant]

Hi everyone,

I'd like to share some updates and open a public discussion about the future of VisPy, specifically around the upcoming VisPy 2.0 project. Over the past several years, work has been progressing quietly behind the scenes on what we believe can become a solid foundation for VisPy’s next generation. We're now ready to open things up and invite the community to participate.

🔧 What’s been happening?

Together with Nicolas Rougier—another one of VisPy’s original core developers back in 2013—we’ve been developing two key components over the past five years or so:

• Datoviz: a scientific GPU-based visualization engine written in C/C++ and built on the Khronos Vulkan API, with auto-generated Python bindings. It's fast, lightweight, it scales to millions of points, and it's now easy to install via pip install datoviz. It already supports a range of features including markers, paths, images, polygons, 3D spheres, 3D meshes (with or without wireframes), text, 3D navigation, basic volume rendering, GUI widgets, and more. Version 0.2.3 is out now, and version 0.3 is coming soon with further improvements (e.g., axes, early Qt integration etc.). Datoviz only provides a relatively low-level API (a bit similar to VisPy's Scene API).

• GSP (Graphics Server Protocol): a simple backend-agnostic protocol built on top of Datoviz, designed to support multiple rendering engines (including Datoviz, Matplotlib, and potentially wgpu/pygfx or other backends). GSP acts as a universal, scientifically oriented graphics layer, offering flexibility and long-term maintainability. GSP doesn't require a GPU backend, but it is designed from the ground up to support it optimally in terms of performance. We'll soon share the specifications, documentation, and examples.

The idea is for VisPy 2.0 to build on top of GSP and Datoviz, providing a higher-level, user-friendly plotting interface. We are just beginning to prototype this layer, and this is where community input becomes especially valuable.

---

🙋‍♂️ How can you contribute?

We’re especially looking for:

• Feedback: What parts of the current VisPy API do you rely on most? What do you wish it did better? How important is backward compatibility to you?
• Ideas: What would an ideal VisPy 2.0 API look like? For instance, if you were to rewrite one of your VisPy 0.x scripts using a clean-slate API, what would it look like?
• Design discussions: Should we adopt a grammar-of-graphics model (à la ggplot2), maintain a Matplotlib-like imperative style, explore more declarative interfaces (like Ziaplot), or prioritize interactivity with something like ImGui plots?
• Volunteers: We welcome help with community engagement, outreach, testing, and API design. No need to write C or shader code—no GPU knowledge is required. Contributions at this level are purely in Python and focused on graphics primitives and user experience.

---

✅ Why this matters

One of the key advantages of the new architecture is that all GPU, backend, and windowing complexity is fully encapsulated within GSP and Datoviz. This significantly lowers the barrier to contributing to VisPy 2.0’s high-level interface—there’s no need to delve into low-level internals. Nicolas and I are actively developing GSP and Datoviz, and we can rapidly adapt and extend these foundational layers to meet the evolving needs of VisPy users.

We see this as an opportunity for the community to play a central role in shaping VisPy 2.0. Our aim is to collaboratively design a modern, intuitive high-level API tailored to the evolving needs of Python-based high-performance scientific and interactive visualization.

---

TL;DR

• Datoviz and GSP provide a strong foundation for VisPy 2.0.
• The next step is to design and build the new high-level plotting interface.
• We’re seeking input on use cases, API design, and potential contributions.
• Community involvement will be key to making VisPy 2.0 successful and relevant.

We look forward to your ideas, feedback, and participation!

[djhoese]

Copied from a related email thread:

This sounds very exciting and very interesting. I've never been good at defining plotting APIs so I'm not sure I can provide any help on that. I can summarize my experience with user interactions with VisPy though and that might guide some of this development and design. I think obviously Lorenzo (CC'd already - brisvag) and the Napari team should be consulted too.

There are a couple of categories of VisPy user. There is the "I understand and like Visuals" crowd and the "I heard VisPy is fast and I want to plot data" crowd.

Visuals

These users understand that they can describe their visualization as a series of primitive Visuals with spheres and lines and meshes as long as they can figure out how to describe their data in a compatible way. Super users understand meshes, but this is only a subset of this group of users. Things that are difficult for this crowd are:

• Cameras and the limitations of the current implementations in vispy
• Low-level OpenGL calls needed either in the Visual itself or outside the Visual to get the visualization they want. Sometimes two Visuals conflict (ex. alpha/depth handling)
• Creating custom visuals has not been completely well defined and requires non-obvious best practice as far as when and how to cache properties so that OpenGL is only talked to when necessary. For example, only upload vertex coordinates if they changed. If someone spent a month or two specifically targeting common use cases I think a few decorators or base classes or helper functions could make custom visuals much easier to create. With VisPy 2.0 I'm not sure if this applies as much, but being able to combine primitive "Visuals" in a custom visual with custom properties that are controlled would be nice.
• Performance and displaying a lot of instances. There are a lot of "why is this slow" that is answered by the unfortunate "you can't just create a ton of Visuals because each one is a separate GL program" answer. The newer instanced mesh visual helps with this, but still. There is the long standing issue of agg lines not allowing for as many ways of specifying coordinates (ex. connections, indexes, etc) as primitive GL lines.
• Updating data in real time

The big thing missing for a small small subset of these users is easily understood multi-camera/viewbox visualizations with understandable interactions. VisPy's parent-child node stuff just doesn't allow for this from my understanding.

Plotting users

These are matplotlib or other plotting library users who want something faster so they come to VisPy. If they saw the old SciPy presentation with the many many plots by Luke then they get heart broken when I have to explain that that visualization was a very specific solution to display exactly what they were seeing. The second they want to add labels and ticks or real world data, performance falls off pretty quickly or code complexity is more than they are used to handling.

For other users they are disappointed by the interface. I don't blame them. The plotting interface in VisPy was never finished and makes it hard to do anything beyond the basic builtin plot types.

[rougier]

Thank for this great feedback @djhoese . For users, one way to start is to post a small example using vispy (1.0) and how you would have like to write it in vispy (2.0) to make it simpler or easier to read.

[timohl]

Looking forward to VisPy2.0 :)

Here my thoughts:

Interactivity

I currently use VisPy in a 3D Labeling Tool (unfortunately not public).
The reason I have chosen VisPy was the "Lasso" example.
I liked how the event.trail() function and the canvas <-> visual transforms made it easy to write a flexible custom solution for my application (extending it to 3D worked very well).

So as a general thought:
Higher level interactivity is great, but might not fit in certain situations.
So, providing also primitive tools (on which the higher level interactivity might build on) would allow users to customize interactivity.

Type Hints

I would love to have proper support for type hints in VisPy2.0.
Static type checking is a major part of modern Python and IDEs (e.g. Pylance/Pyright and mypy) and Python is extending it in every new version.
It can also improve the documentation by a lot.
Adding a library without type hints into type checked code can be very annoying and might discourage some people from using it at all.

Usually, libraries are older than the Python typing system and adding typing support requires a lot of work for a big existing codebase.
VisPy2.0 does not have that excuse and should start with type annotations from the beginning.

I have been working on adding type hints to Open3D for quite some time now.
This required me to add and review several PRs to improve typing support in pybind11 (the Python/C++ binding code used in Open3D).

So, I would be happy to help here as well.
If you need any help concerning type hints, feel free to ping me in issues or PRs.
Is the vispy/vispy2 repo the correct place to keep an eye open?

[djhoese]

I think whoever is willing to do the work can decide, but my vote is for Cython or SWIG if really complex, but even CFFI seems better than ctypes.

I'm curious @rossant what feature you needed that required writing your own header parser.

Also, the worst case for someone using a new version of python would be that their system needs to have a compiler to build the extensions from source. Not great, but not terrible. Plus, you can have github's dependabot update cibuildwheel automatically. The PR created by dependabot includes what new versions of Python or PyPy or other runtime are now available (and enabled by default) so then it is just up to the maintainer to release a new version. Usually active libraries/packages have frequent enough releases that this isn't really a problem though.

[rossant]

Could you clarify which existing tools can take a C header file with function signatures and automatically generate Python bindings? I haven't found many that can do that (SWIG maybe?), but I might have missed some. For the API reference documentation, I also had to parse my functions anyway. I have to say that LLMs make tasks like this almost trivial now, so pursuing this approach was very straightforward.

In any case, I think this is basically a solved problem for Datoviz. I have a GitHub Actions pipeline that builds pip wheels for macOS (arm and amd64), Windows 64-bit, and Linux 64-bit. It compiles the libdatoviz.so/dylib/dll, bundles it along with a few other dependencies into the Python wheel, and uploads everything to PyPI. It's fully transparent to users—pip install datoviz is all they need. So far, it has worked very well for me and existing users, and it's quite fast. The library is designed so that you don’t need to make many calls to the C functions, even with large datasets, so overhead is a non-issue in most cases.

We can certainly revisit this later if severe performance issues arise, but for now, I consider this a solved problem for Datoviz.

[djhoese]

Fair point(s). I guess I was mostly surprised that there weren't more existing tools that did what you wanted to do. My understanding, with admittedly limited experience, is that CFFI can do this by reading the header file(s) and loading the .so:

https://cffi.readthedocs.io/en/stable/overview.html#simple-example-abi-level-in-line

Regardless, do what you have to do.

[almarklein]

FWIW, we have a simple custom header parser in wgpu-py too. cffi can indeed parse the header file and automate the bindings, so that you don't have to specify the signatures of the C-functions. That's of great help, but if you want to do a bit more, you need more info. Our parser does a combination of examining the result of cffi, and some manual parsing of the header.

[rossant]

I might have tried CFFI at some point but ended up deciding not to use it, I can't remember what the problem was.
Indeed, my parser is somewhat tied to how my headers are organized. If anyone's curious, the code is here.

[rougier]

And also https://github.com/vispy/gsp

[rossant]

Datoviz v0.3 is out! Check it out at https://datoviz.org

[krokosik]

A killer feature for me would be a seamless integration with GPU stored arrays, for example in Torch, Jax or Cupy. I'm not that familiar with GPU specifics sadly, but being able to render them without the GPU -> CPU -> GPU transfer would be pretty great. The use case for that for me would be running realtime simulations in 2D spaces, for example aritificial life sims like Lenia.

[rossant]

I agree! This is one of the main features that I plan to implement in Datoviz v0.4 (planned for 2026...). In the meantime, I have a proof of concept of Vulkan-CuPy integration (sharing the same GPU buffer between Vulkan for visualization, and CuPy for compute).

[krokosik]

Incredible! Can't wait for 2026 then 😅

[rossant]

I think you can already try with the current version of Datoviz, and CuPy, with GPU -> CPU -> GPU transfers: far from optimal, but you should still get decent performance if you don't have huge datasets. I believe @ron-adam has tried already?

[krokosik]

Yes, I also got pretty decent performance with pyqtgraph image and their cupy integration, but it also does CPU transfer AFAIK.

[krokosik]

Also, our lab relies on multiple pyqtgraph instances with realtime plots. This places a burden on the CPU and performance would be a strong incentive to switch to VisPy (especially that it works well with Qt!). However, we lack some features, especially in terms of mouse control and the pyqtgraph context menu.

My point is that targeting end-users from the scientific background that are not programmers would probably help increase the adoption rate of this project. I mention pyqtgraph because it seems the most widely used to me, not only in custom lab applications on GitHub, but also in frameworks like https://github.com/Ulm-IQO/qudi-core or https://github.com/labscript-suite/labscript-suite

To sum up I believe that feature parit (or even API compatibility) would be highly beneficial for this project.

[PrasannaPaithankar]

Is it feasible add a feature to export the render to a 3d file format like .glb

[rossant]

Good idea, although this might fit better in the GSP protocol. cc @rougier

[rowanG077]

All else being equal a pain point is the lack of good type hints in vispy. I often have to have the vispy source code open to be able to do more complex stuff,

[rowanG077]

I took some time to collect my thoughts. very happy to see this since I mainly use vispy when I need performant visualizations. And a growing worry was whether I building on unmaintained software. But it seems this was unfounded.

I can at least give some feedback what I would like to see :).

What parts of the current VisPy API do you rely on most? What do you wish it did better?

I use 3D canvas the most and I wish it handled depth better. There are a ton of visual issues when combining markers meshes, lines etc. in a single scene.

How important is backward compatibility to you?

Personally I don't care at all for my projects. Having a great library is much more important to me. I can always spend time porting.

What would an ideal VisPy 2.0 API look like? For instance, if you were to rewrite one of your VisPy 0.x scripts using a clean-slate API, what would it look like?

Two pain points for me are object selection in scenes and event propagation.

Ideally I would like every visual to just support a selected event or something with visual specific metadata. Markers should contain what marker was clicked. Meshes should include which vertex/edge/triangle was clicked, Box should contain which line or vertex was clicked etc.

Event propagation should allow us blackhole events. For example if a canvas input event is done I should be able to stop it from propagating to all visual/cameras in the scene. This will save a ton of custom cameras I have implemented with the sole reason of disabling an event in some cases.

Another small nit is that there is no text outline feature. Especially if I add text to colorful scenes I now put a full solid rectangle behind it. Whereas the better solution would be to have an outline on the text so it is well readable regardless on what is behind it.

Design discussions: Should we adopt a grammar-of-graphics model (à la ggplot2), maintain a Matplotlib-like imperative style, explore more declarative interfaces (like Ziaplot), or prioritize interactivity with something like ImGui plots?

I'm pretty happy with the visual based API that is currently in use.

[rossant]

Thank you for your valuable feedback!

[ron-adam]

Looking forward to this.

This may be helpful...

I'm currently working on a pure python graphics display system. With GPU programming becoming more common outside of display devices, I wanted to see how it would look if it was all done in python. Except for the final transfer to the display device.

This actually works fairly well when Cupy and Numba is used to speed things back up. I hope to have a basic (and cleaned up) version on my github page in about a month. What I'm finding is having a well defined protocol for the data arrays helps. I'm using Numpy ordering, (row, column, rgba) order to maximize compatibility with Numpy functions. When everything matches up, it just works. For volumes its, (row, column, depth, rgba) order.

The thing that really comes out in doing this is the power of samplers. In OpenGL it is tucked away in the shaders and it's not obvious how important samplers are. When it's taken out into Python code, we get Numpy like array operations with floating point indexing.

What that means is doing projection operations from one array to another gets very easy. Unlike integer indices, samplers use normalized floating point indices. So if I create a floating point indices from the target shape, then apply it to the source array, I get a new array of the target size. This can be smaller, larger, or equirectangular, etc., it depends on how the indices are calculated.

With Numba it is done on the GPU in parallel, (Looks similar to shader code actually, just in python syntax.) and it is still relatively fast but not fast enough yet. (This will continue to improve as newer and faster computers become available.)

The samplers can work as nearest, linear, or cubic. (or other) Mine use a B-Spline sampler that only needs 9 samples instead of 16 for near cubic quality interpolation. But samplers can be extended further. Raytraced images is a sampling operation. We can use matrix operations on the indices to rotate, skew, and resize, the indices before sampling.

The samples are per pixel on the target (display window), but have no restraints on the source due to the floating point sampling. So projecting images from on surface to another becomes just a few operations on whole arrays. (in python code).

This does not mean that shaders should not be used. But it pulls everything out of the box so we can look at in a different light. Some parts we can put back in the box and combined again where the specialized hardware can be used to gain back the speed.

I see a main use as a way to construct and prototype complex cameras. Once they work, then it can be rewritten as a shader.

Eventually as GPU and parallel processing increases, the state of video cards may become more like what happened to sound cards. Where computers have a basic interface to the display, but much of it is done in software in higher level parallel capable languages. We aren't there yet, but it's getting closer. My project is an attempt to explore in this direction early.

I hope to have backend window objects available from different graphic libraries. The windows still need to interact with the OS, and provide an event loop with messaging. Having different backends ensures it can run on more systems.

So we get this arrangement [Window manager <==> View managers <==> Cameras <==> Data]. With indices and messages are passed down, and images passed upward in the display stack. The Window object is the interface to the OS, and hardware. It expects finished images to display in a window. This arrangement is a tree that may have many branches down to the data. Callbacks may be placed in the tree for adding additional features. Such as sending an image to a file. Or diagnostics.

A camera is a complex sampler. and these may be stacked, and ordered as we go down the stack to the data.

A 3D perspective scene may be a stack of sampler references for each pixel. Like ray tracing, but we transverse samplers to get to the data instead of surface reflections. And wherever that pixel index finally lands, determines the color sent back up to the window.

Building charts can also be a matter of projection and sampling different parts from one place to another. In python, these are just advanced slices. But normalized samplers are not limited to integers and can do much more.

This kind of image manipulation is usually done in high end game engines, but it can can have a wider more general use.

[almarklein]

Interesting! Some comments, maybe they are helpful, maybe not :)

• With wgpu-py you can do GPU compute that runs on any hardware (in contrary to Numba that'd need an NVidia GPU). It's not used a lot yet, and there's no Python-to-wgsl that I know of yet, but there are cool opportunities for cross-platform / cross-device compute this way, and I'd be happy to help/advice if you go this route. Feel free to ping me.
• For effificient image resampling:
  • This blog post is interesting.
  • This 12-tap Mitchell filter was inspired by it.