@kmuehlbauer @larsoner (CC @aaru143), I'm getting kind of annoyed of the organization of the example scripts. I think maybe back in the day most of these were copied from @rougier and glumpy. But we've had various additions and sometimes the style is different and sometimes there is a really good example in tutorial but not in basics even though the tutorial example is a better example of something "basic".
Thoughts on reorganization or some other thing I'm not realizing would be bad if we reorganized? (I know links would be broken but I think we could figure it out)
I'm working on the gloo "getting started" documentation and was getting annoyed by wanting to point to some things in basics and at things in tutorial.
We can think about the organization later if no one brings up an argument against doing it. My current though is a "basics" section that is the basics of VisPy (gloo - buffers, shaders, timers, etc, scene - cameras, timers, etc). Then we could move some of the "this is an example of how to use this Visual" to a "demo" directory or something like that. This is off the top of my head, but I think it goes along with a "here's how you do things in VisPy" versus a "here's everything VisPy can do".
I'm not completely against moving them to another repository but would like to avoid another git submodule if we can. I'd be more excited about an external repository if all the examples could run in a jupyter notebook and we could get a binder session running. Right now I don't want to start advertising jupyter visualizations as "this is where VisPy shines"...because it doesn't. Not even close.
vispy-web or something. If people wanted the jupyter widget then they install that and that would include all the javascript stuff. It could probaly be in the vispy.js repository itself. Vispy (core) doesn't have the ability to include outside backends I don't think, but yeah that would be one option.
@djhoese Maybe I just have to be more open minded, :grin: .
Vispy (core) doesn't have the ability to include outside backends I don't think, but yeah that would be one option.
How easy/hard would it be to entangle backends / refactor out from vispy core library into backends repo?
@kmuehlbauer @larsoner FYI I still haven't found anyone to take over the "Service Contract" part of my CZI funding. The original idea was that someone who wanted to work on vispy but didn't have the time would be able to if they just had the money. However, it seems like most people who have shown interest in vispy lately are grad students who don't have time (story of vispy's life). There are a few other people I'm thinking of contacting, but I think I'm going to turn this funding into an actual service contract where I layout tasks that could be attempted and hire someone to do them. There may be a group at the University of Wisconsin here that might be able to do it. My current (off the top of my head sort of):
- CuPy support/handling - Use data directly from GPU memory that was computed with CuPy.
- Better dask support and/or "data source" overhaul - Better handling for different data sources. This may morph into something like a Buffer class that satisfies the numpy array interface(s). I think this would let VisPy use any data source (including cupy). In the cupy case we'd have to make sure not to copy the data into CPU memory and then back to GPU but still.
- WebGPU stuff (CC @almarklein) - How hard would it be to refactor vispy to prepare for a webgpu "backend" or interpreter. Would it require a new "middleware" instead of GLIR (WebGPU IR - WGIR) to be the most effective?
- Optimize and improve jupyter widgets. The old SciPy presentation showed a fast jupyter widget. What happened? Why does it suck now?
- Refactor/rewrite to use OpenGL 3+ or OpenGL core profiles. In the past I had explored using a core GL profile on my old macbook instead of the "compatibility" profile. OpenGL complained that vispy wasn't doing things in the right order or something like that. This would be a big hurdle of moving to new versions of OpenGL. Or maybe with WebGPU this would be the same goal.
- Scene graph optimizations. In most game engines (from what I understand) a SceneGraph is meant to order and optimize the order of drawn objects so it doesn't have to switch GL programs all the time, but only buffers and other things. This task would likely involve investigating re-using the "collections" that were copied from glumpy (CC @rougier ).
Other ideas?