📣 Help shape the future of VisPy 2.0 – ideas, feedback, and contributors welcome! #2661
Replies: 8 comments 21 replies
-
|
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. VisualsThese 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:
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 usersThese 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to VisPy2.0 :) Here my thoughts: InteractivityI currently use VisPy in a 3D Labeling Tool (unfortunately not public). So as a general thought: Type HintsI would love to have proper support for type hints in VisPy2.0. Usually, libraries are older than the Python typing system and adding typing support requires a lot of work for a big existing codebase. I have been working on adding type hints to Open3D for quite some time now. So, I would be happy to help here as well. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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— We can certainly revisit this later if severe performance issues arise, but for now, I consider this a solved problem for Datoviz. |
Beta Was this translation helpful? Give feedback.
-
|
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 https://cffi.readthedocs.io/en/stable/overview.html#simple-example-abi-level-in-line Regardless, do what you have to do. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I might have tried CFFI at some point but ended up deciding not to use it, I can't remember what the problem was. |
Beta Was this translation helpful? Give feedback.
-
|
And also https://github.com/vispy/gsp |
Beta Was this translation helpful? Give feedback.
-
|
Datoviz v0.3 is out! Check it out at https://datoviz.org |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
Incredible! Can't wait for 2026 then 😅 |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I also got pretty decent performance with pyqtgraph image and their cupy integration, but it also does CPU transfer AFAIK. |
Beta Was this translation helpful? Give feedback.
-
|
Also, our lab relies on multiple 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 To sum up I believe that feature parit (or even API compatibility) would be highly beneficial for this project. |
Beta Was this translation helpful? Give feedback.
-
|
Is it feasible add a feature to export the render to a 3d file format like .glb |
Beta Was this translation helpful? Give feedback.
-
|
Good idea, although this might fit better in the GSP protocol. cc @rougier |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
✅ 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
We look forward to your ideas, feedback, and participation!
Beta Was this translation helpful? Give feedback.
All reactions