Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 24 19:23
    djhoese synchronize #2220
  • Sep 24 19:17
    djhoese commented #2220
  • Sep 24 19:17
    djhoese labeled #2220
  • Sep 24 19:17
    djhoese review_requested #2220
  • Sep 24 19:17
    djhoese assigned #2220
  • Sep 24 19:17
    djhoese opened #2220
  • Sep 24 18:21
    djhoese commented #2219
  • Sep 24 17:54
    djhoese commented #2219
  • Sep 24 17:51
    hershey890 commented #2219
  • Sep 24 17:51
    hershey890 commented #2219
  • Sep 24 17:49
    hershey890 commented #2219
  • Sep 24 17:49
    hershey890 commented #2219
  • Sep 24 17:12
    djhoese labeled #2219
  • Sep 24 17:12
    djhoese commented #2219
  • Sep 24 17:04
    hershey890 opened #2219
  • Sep 24 14:56

    djhoese on main

    Use glfw wrapper from the 3rd p… (compare)

  • Sep 24 14:56
    djhoese closed #2215
  • Sep 24 14:56
    djhoese closed #2214
  • Sep 24 14:56
    djhoese edited #2215
  • Sep 24 14:56
    djhoese labeled #2215
David Hoese
@djhoese
@j9ac9k Hi! So a couple things, glLineWidth is deprecated in the OpenGL spec. Support for it will depend on the GPU vendor/drivers. The "traditional" way of changing the width of lines is to do a more complex drawing "agg" lines where they are actually drawn as triangles. This allows you to do things like antialiasing as well as have custom caps and joins between line segments. The LineVisual in vispy has two drawing methods for this: "gl" for the regular/basic lines like you are using and "agg" for the other method. The problem is that the agg algorithm in vispy doesn't provide all the features of the "gl" method. For example, being able to provide individual line segment pairs for your positions or providing an index array that indexes into an array of vertex positions for what lines to draw.

Also, FYI, you can see some of this mentioned in the vispy roadmap (https://vispy.org/roadmap.html) but we plan to slowly remove OpenGL use in VisPy as technologies/libraries like datoviz/vulkan and wgpu-py/wgpu because more available to the python community. @rossant and @almarklein are the ones leading these technologies in our community. Our roadmap discusses how we'd like to move to these technologies as a "graphics backend" in the future.

This is one reason pyqtgraph may want to think about switching to vispy in the long term too as our hope is that the top level should stay the same in VisPy (or close to it) and the backend should just be swappable to these newer more capable technologies. No pressure on switching to vispy, but wanted to bring it up in case it influences the rest of this discussion.

Oh I also didn't say, glLineWidth does not allow for per-vertex widths. If you have a limited set of widths (say one "skinny" and one "wide" width) then it maybe useful to have separate GL programs for each set. This would decrease performance (frames per second) but you're only drawing lines so it shouldn't be too bad.
Ogi Moore
@j9ac9k

Hi David, thanks for your reply. Our libraries definitely seem to have a good amount of overlap so I'm super excited for where collaborative efforts can lead. I have my hands full today with parenting duties today but I'm going to have a bunch more questions! I'm curious what vispy integration into pyqtgraph would actually look like. For example, do I not import opengl and import vispy instead or would pyqtgraph aim to act as a thin wrapper to vispy's graphing methods? Is there a use-case you would recommend as an example? Also by extension, what is vispy's relationship with Qt (for example, do you use the GraphicsView framework?).

I'm actually really glad to see that vispy is making plans to move on from OpenGL. It seems like Windows/macOS has been trying to deprecate its openGL capability for some time.

David Hoese
@djhoese

@j9ac9k Vispy has multiple backends for various GUI frameworks; one of them being Qt. We strictly use QOpenGLWidget:

https://github.com/vispy/vispy/blob/f6b19fb03b9d2c391bc24a15e3de7b4c836894dc/vispy/app/backends/_qt.py#L80-L83

I have honestly only used pyqtgraph a very little bit. Mostly the GradientWidget for a work project where we needed to make a colormap editor. Other than that, I'm sure @campagnola could describe how he saw pyqtgraph and vispy fitting together. Even the pyqtgraph website still says this near the bottom:

VisPy is a new 2D/3D visualization library based on OpenGL that is developed as a collaboration between the authors of PyQtGraph, VisVis, Galry, and Glumpy. It is presently in early development and has a narrower scope than PyQtGraph--it will focus on visualization without the GUI toolkit features provided by PyQtGraph. In the long term, we hope VisPy will be able to replace Qt as the rendering engine for 2D graphics, and replace the pyqtgraph.opengl 3D system entirely. More about VisPy here.

I think the way I see it is that, depending on how some low-level pyqtgraph stuff works, you could create a VisPy Canvas object which has a .native property which is an actual QWidget that can be added to any Qt GUI. From there, you can update the various vispy elements and call canvas.update() and it will update the visualization
Ogi Moore
@j9ac9k

@campagnola and I have briefly chatted about VisPy integration some time ago, if memory serves, he was thinking it would act as a Graphics View replacement.

We support an optional openGL acceleration for our 2D plots where we migrate from QWidget to QOpenGLWidget, where the API is supposed to maintain consistency, but outside of drawing thick lines with minimal performance hit (a frequent feature request) we haven't see much performance gains; although I suspect that has more to do with our implementation of OpenGL than anything else. Our 3D implementation is where I see the bulk of the gains potentially being feasible (which we also use QOpenGLWidgets.

I clearly have some homework to do with regards to experimentation with VisPy, it's calls and to try and see how pyqtgraph could make use of it.

David Hoese
@djhoese
@j9ac9k Sounds good. I should note that the high-level plotting interfaces on vispy are rather limited. It is the part of vispy that needs the most work as far as user facing interfaces. It isn't that we don't want them to be better, but that there are so many other low-level things that we've had to work on and the plotting has been "good enough" so far. If pyqtgraph can drive the future design of the plotting stuff that would be great.
Ogi Moore
@j9ac9k
@djhoese oh I get the whole "this is limited, we want to do better, there are so many maintainer/contributor hours"; no need for justification :D
David Hoese
@djhoese
@j9ac9k Gotcha. Just wanted to make sure that if the decision of pyqtgraph adopting any part of vispy came to "well it doesn't do what we want in X way" that it isn't like we aren't willing to make changes, updates, redesigns to support pyqtgraph's use case.
Ogi Moore
@j9ac9k

@djhoese our libraries have (some) overlap, they are both actively developed, if we decide to have some level of integration, some back-and-forth is reasonable to assume, we won't be so quick to take our ball and go home. What I suspect would more likely be the case is we have questions about how to efficiently do x, y, z.

I guess first question involving Qt comes in the form of, do you support Qt6?

I guess my first question would be, which portion of vispy should I attempt to wrap/utilize using pyqtgraph? I imagine if I attempt to wrap vispy.plot or vispy.scene I would be replicating a bit too much of pyqtgraph, and that's likely the areas you're hoping to expand capability on.

Should I aim to focus wrapping vispy.gloo or the "visuals" functionality in the docs? https://vispy.org/getting_started/visuals.html

David Hoese
@djhoese
@j9ac9k We had someone add the proper imports for PySide6/Qt6 but not PyQt6 (if that is a thing).
I think you should use the SceneCanvas if you do adopt anything. Anything lower than that (basic Visuals or gloo) will likely be deprecated or changed in some way as we move away from OpenGL. That said, we haven't even done a proof of concept of using datoviz or wgpu as a backend for vispy so I'm not exactly sure what the Visuals will look like. There are the "raw" Visuals and then there are lightly wrapped versions of those visuals to make them "scene visuals" that understand hierarchy and more complex transforms. These "raw" visuals are the ones I'm not sure I can guarantee will stay exactly as-is
Ogi Moore
@j9ac9k
PyQt6 took a little more work to support than PySide6; we supported both eventually. Things got better with PyQt6 6.1; we removed support for Qt 6.0 on the first release after 6.1 was released ...
regarding the deprecation of openGL, that makes sense... At this point I'm not looking for an API that I can depend on consistent results for all time; just looking for a proof of concept ... I'll try and carve out some time this week to dive into it since I'm about to wrap up the PR I was previously working on.
Ogi Moore
@j9ac9k
@djhoese I seem to remember that vulkan was not going to be supported on macOS, I assume that macOS is a platform you plan on supporting with the newer graphics library backends?
David Hoese
@djhoese
Yes, but I depend on @rossant who is the datoviz creator/maintainer and uses a mac for his work. It may require extra drivers but my understanding was that there is a vulkan<->metal conversion available. Not sure if it is provided by default or if extra stuff needs to be installed
Ogi Moore
@j9ac9k
:thumbsup:
David Hoese
@djhoese
@almarklein I'm putting the conda-forge package together for jupyter-rfb.
Noticed that jupyter_packaging isn't listed in the setup_requires of the setup.py. The conda-forge recipe generated complained about it
Almar Klein
@almarklein
mmm, odd. I'd expect the coockiecutter to produce a sound setup.py
David Hoese
@djhoese
FYI I just enabled https://github.com/vispy/vispy/reported_content. This means that contributors/users should be able to report abusive or disruptive stuff on github. I didn't know this existed but it showed up on the community report: https://github.com/vispy/vispy/reported_content
Almar Klein
@almarklein
interesting!
Lorenzo Gaifas
@brisvag
I'm trying to implement the clipping_plane logic to the markers visual. I figured it would be easy, but I'm now realizing I'm very confused about how GLSL passes around variables. How can I set a boolean variable in the vertex shader and pass it to the fragment shader (so I can discard when clipped)? Or alternatively, how should I approach this?
David Hoese
@djhoese
@brisvag you should be able to make a float varying: https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/varying.php
Lorenzo Gaifas
@brisvag
I tried that, but the value I compared later did some weird stuff. If I get it right, what is happening is that the float is being interpolated between fragments, so I can't quite use it as I wanted (set to 1 if clipped, set to 0 if unclipped, compare). Should I just rethink the set/check logic to work with interpolated values then?
Lorenzo Gaifas
@brisvag
I think I worked it out. However, I'd like feedback on how solid the logic is. #2176 !
David Hoese
@djhoese
VisPy 0.8.0 is out on PyPI!
Kai Mühlbauer
@kmuehlbauer
:rocket:
Almar Klein
@almarklein
w00h00
David Hoese
@djhoese
@almarklein If you see this...monthly meeting right now
Almar Klein
@almarklein
Oh crap, I was planning to come, but we had a friend over and I completely forgot. Sorry!
David Hoese
@djhoese
no big deal. We talked a long time about PolarTransform stuff that Kai is working on. See the meeting notes if you are curious otherwise.
Lorenzo Gaifas
@brisvag
I'd love some suggestions on #2197!
Kai Mühlbauer
@kmuehlbauer
@brisvag This looks really great as a filter. I've added the code to the example itself and it works smoothly.
Lorenzo Gaifas
@brisvag
@kmuehlbauer can you check if I broke it for you?
Kai Mühlbauer
@kmuehlbauer
I'll let you know (after lunch). Thirty minutes or so.
Lorenzo Gaifas
@brisvag
yeah no rush, thanks :)
Kai Mühlbauer
@kmuehlbauer
Still working :-)
Lorenzo Gaifas
@brisvag
sweet!
Lorenzo Gaifas
@brisvag
Something really bad is going on with git and the submodules... I can't merge nor rebase without errors, no matter what I do (delete the submodules, don't do it, ...). When I finally managed to go through without errors, I get a PR with a million commits (even though those commits exist in main already, somehow???). Any insight?
Lorenzo Gaifas
@brisvag
ugh, I got it I think...
David Hoese
@djhoese
@brisvag Let me know if you still need help with the submodules. Sorry, I didn't see this
also getting ready to release 0.8.1 but github_changelog_generator is choosing not to include all the issues that were fixed
Lorenzo Gaifas
@brisvag
@djhoese I'm writing here to make sure it wasn't lost in the conversation on the PR. I'd like some feedback on this comment to go forward with that PR!
David Hoese
@djhoese
@brisvag I'm a little swamped with other projects right now, but I've skimmed what you wrote and am a little confused. You said you removed symbol, did you mean scaling. You said the add_data function, did you mean set_data?
Lorenzo Gaifas
@brisvag
No pressure, I just wanted to make sure it didn't get lost :) Right, it seems I wrote that comment a bit sloppily. I did mean set_data, sorry! I removed both symbol and scaling. My feeling is that set_data should only be used for things that can vary on a per-marker basis. Symbol and scaling are just parameters of the visual, not really "data". Is that right thinking?
David Hoese
@djhoese
"right thinking" is relative. Works for me
Lorenzo Gaifas
@brisvag
Cool!