Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:32
    rougier commented #2000
  • 20:14
    djhoese commented #2000
  • 19:48
    rossant commented #2000
  • 18:47
    djhoese commented #2004
  • 18:45
    ThenTech edited #1918
  • 18:43
    ThenTech edited #1993
  • 18:32
    djhoese synchronize #2004
  • 18:30
    djhoese commented #2004
  • 18:27
    rougier commented #2004
  • 18:24
    djhoese commented #2004
  • 18:23
    djhoese synchronize #2004
  • 17:06
    rougier commented #2004
  • 17:02
    rougier commented #2004
  • 16:58
    rougier commented #2004
  • 16:57
    rougier commented #2004
  • 16:55
    djhoese commented #2004
  • 16:53
    rougier commented #2000
  • 16:47
    djhoese synchronize #2004
  • 16:44
    djhoese commented #2004
  • 16:35
    rougier commented #2004
Kai Mühlbauer
@kmuehlbauer
Yes, saw that now, we might have to use:
personal_token
David Hoese
@djhoese
ok I'll make the edit directly on github. One sec...
Kai Mühlbauer
@kmuehlbauer
Fingers crossed
Kai Mühlbauer
@kmuehlbauer
Great, seems to work now
David Hoese
@djhoese
thanks @kmuehlbauer
going offline for a while. Holiday in the US so not working today
Kai Mühlbauer
@kmuehlbauer
No problem, have a nice time with the family!
David Hoese
@djhoese

@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)

Kai Mühlbauer
@kmuehlbauer
@djhoese I have thought about reorganization that when working on the windbarb example. I
But I've no idea how it should be reorganized. We could think about putting the examples into a dedicated repository.
David Hoese
@djhoese

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.

David Hoese
@djhoese
@rossant @campagnola or maybe @larsoner Can you make me an owner of https://groups.google.com/g/vispy-dev
hm Eric you may not have permissions either
Eric Larson
@larsoner
indeed I do not, just @rossant and @campagnola and I doubt they are on gitter
David Hoese
@djhoese
I just DM'd Cyrille on twitter about it. He's liked vispy tweets recently so I'm pretty sure he's actively checking it.
David Hoese
@djhoese
Ok @larsoner and I are now owners on vispy-dev. I realized we weren't on the regular "vispy" group but asked Cyrille to do that too. @kmuehlbauer are you a member on both of those groups? Do you want to be an owner?
ah and now vispy is done too
Note to self: Contact Cyrille on twitter for quick responses.
Kai Mühlbauer
@kmuehlbauer
@djhoese I'm open for anything which helps, but this would need a Google account, right?
David Hoese
@djhoese
looks like your uni-bonn.de email is used for the regular "vispy" group
for vispy, given the lack of maintainership, I think having as many people with access is a good thing
Kai Mühlbauer
@kmuehlbauer
OK, of this is email based, just add me.
David Hoese
@djhoese
@kmuehlbauer add you with that uni-bonn.de email address?
Kai Mühlbauer
@kmuehlbauer
@djhoese If that's possible, yes. I can have a look tomorrow, if I can get access (if I find the credentials :grimacing:)
David Hoese
@djhoese
@kmuehlbauer done
on both
David Hoese
@djhoese
@kmuehlbauer These 40+ minute Windows runs on Azure are killing me
Kai Mühlbauer
@kmuehlbauer
@djhoese We could remove the oldest python run and we could split this in several parallel windows runs.
David Hoese
@djhoese
I'm curious why it is slow in the first place
Kai Mühlbauer
@kmuehlbauer
Windows is known to be notoriously slow in CI...
David Hoese
@djhoese
@kmuehlbauer Are you required to use Windows for your job?
I just don't get the hard requirement some organizations have on using it. I mean I do, it costs money to have expert IT staff and security for multiple operating systems, but still.
Kai Mühlbauer
@kmuehlbauer
@djhoese No, I'm happy to use linux on our workstations, laptops and servers. If there would not be conda-forge, I would have dropped Windows testing for packages I maintain years ago.
David Hoese
@djhoese
haha same
David Hoese
@djhoese
@kmuehlbauer I thought about your javascript "hatred" and thought of a possible solution. We could move the jupyter/webgl backend to a separate python package 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.
Kai Mühlbauer
@kmuehlbauer

@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?

David Hoese
@djhoese
oh that's an idea. I think the first step would be to refactor the backends to not be import-based and rather be classes or something else that gets initialized. The "oops you imported the backend and now you can't use another one" problem would be annoying if there were external packages involved.
I think we could take advantage of setuptools entry_points to discover the other backend packages though.
David Hoese
@djhoese

@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):

  1. CuPy support/handling - Use data directly from GPU memory that was computed with CuPy.
  2. 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.
  3. 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?
  4. Optimize and improve jupyter widgets. The old SciPy presentation showed a fast jupyter widget. What happened? Why does it suck now?
  5. 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.
  6. 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?

My plan is to make a new github label for this topic and create issues for each of these ideas.
Eric Larson
@larsoner
that looks reasonable to me
might be worth making the roadmap on a website or the Wiki and leaving issues for more targeted stuff, for example https://pandas.pydata.org/pandas-docs/stable/development/roadmap.html https://docs.scipy.org/doc/scipy/reference/roadmap.html https://mne.tools/dev/overview/roadmap.html
David Hoese
@djhoese
Another one I just remembered this morning:
  1. Fix parent<->child relationships in SceneCanvas so that multi-view/multi-camera views are possible.
  2. More work on shared context work (just thought of this one)
darn it gitter, I wanted to continue my numbering
yeah a roadmap would be good
David Hoese
@djhoese
@kmuehlbauer @larsoner I'd like to create a new PrecisionWarning(UserWarning) class. Any ideas where I should put it? vispy.util.precision (new module)?
eh maybe I'll just use a normal UserWarning
David Hoese
@djhoese
Some of my recent PRs are failing and I think it is an OpenGL driver update on GH Actions that is optimizing out the translateuniform in STTransforms when it is 0. That's my current best guess.