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.
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.
@j9ac9k Vispy has multiple backends for various GUI frameworks; one of them being Qt. We strictly use QOpenGLWidget:
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.
.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
@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.
@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
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?
float varying: https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/varying.php
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?