https://github.com/vispy/vispy/projects/1

• David Hoese (@djhoese)
• Almar Klein (@almarklein)
• Talley Lambert (@tlambert03)
• Eric Larson (@larsoner)
• Kai Muehlbauer (@kmuehlbauer)
• Juan Nunez-Iglesias (@jni)
• Nicolas Rougier (@rougier)
• Cyrille Rossant (@rossant)

• Task 1: Work on additional texture format support in the ImageVisual (djhoese, rougier, tlambert03, almarklein, kmuehlbauer)
• Task 2: Ticket Review (larsoner, kmuehlbauer, rougier)
• Task 3: CI Wheel Building (kmuehlbauer)

~23 issues closed. 4 PRs merged. Many more commented on.

Most time of the ImageVisual work was spent debugging precision issues causing failed tests. Trying to add additional texture formats did not lead anywhere (ex. r32ui).

• Task 1: Presentation by Cyrille (rossant) on datoviz and vulkan. See https://datoviz.org/. Slides
• Task 2: Presentation by Almar (almarklein) on WebGPU, wgpu, wgpu-py, and pygfx.
• Task 3: Discussion on the future of Python.
• Task 4: Continued ImageVisual work and work on VolumeVisual (djhoese, tlambert03)

The main points of the discussion were how could VisPy be reworked to benefit from Datoviz and/or wgpu-py. These projects focus on lower level functionality that is accessible to scientists, but VisPy's high level SceneCanvas and plotting APIs are still useful. This is especially true when the underlying graphics/visualizations are done well. The question was raised of what should VisPy development focus on in the coming years and how can this be turned into a more public Roadmap document.

One option would be to drop Jupyter/WebGL support and focus on desktop OpenGL; pushing the GLSL/OpenGL compatibility to OpenGL 3 or 4 and dropping support for 2/ES like we try for now. This would be a lot of work and it was suggested that VisPy should work more on separating out Visuals as the lowest level user-facing interface offered by VisPy and instead depend on other libraries for everything lower (gloo, datoviz, wgpu, etc). To do this means we need to summarize the existing Visuals in VisPy and define "primitive" Visuals or Graphics (datoviz term) that are needed from a low-level library in order to serve as a graphics backend for VisPy. This work will be defined by a Wiki page to be created in the future.

None of this means that VisPy will be dragged through a future where it doesn't belong. If in the future it becomes clear that the functionality planned for VisPy should be provided by another (new or existing) library, then so be it. OpenGL itself is not going away right now, but its flaws are showing.

One suggestion from Eric Larson was to change the Jupyter widget to instead be a stream of PNGs to the browser. This means all rendering happens on the server and we don't have to worry about web socket delay (at least not like we do now), parsing GLIR, and WebGL compatibility. Dave Hoese will make an issue for this topic.

To keep interested parties involved in VisPy it was decided that we should try to have monthly (or other time frame) meetings. Dave Hoese will send out emails to schedule this in the future.