The future of pyqtgraph

[john lunzer]

I would like to address concerns about the future of pyqtgraph. I want to start by saying I'm not judging anyone or complaining. I fully understand what free software implies. I also regularly use and love pyqtgraph and am thankful to the developer(s).

I'm mainly looking for an honest review on the future of python performance plotting and graphing.

Throughout 2014 the commits to pyqtgraph steadily dropped and haven't rebounded. I also saw a marked drop in commits to vispy (which has been touted as the future of python performance graphing) in about Oct 2014.

Pyqtgraph currently provides a mostly complete (and awesome) high level interface for performance graphing (the pyqt part is a huge bonus). I haven't used Vispy but from the little I've read/seen it doesn't look like vispy has anything remotely resembling a complete high level interface, which puts it out of the hands of most people who just want some fast plotting. 

Given these observations, what is the 2015 and beyond outlook for python performance graphing with a complete high level interface? 

Are there any plans (or even needs) to ratchet up the development of pyqtgraph?

Thank you in advance for responding.

[Luke Campagnola]

My thoughts:

1. PyQtGraph development has slowed down due to my commitments to life and other projects. It's clear I am the major bottleneck here and I would love to transition toward having a larger group of core developers to review incoming PRs and handle issues.

2. On the other hand, pyqtgraph has also reached a certain level of maturity and doesn't require nearly so much active development anymore. (although there are still long-standing bugs and popular feature requests that need attention.) 

3. VisPy has become more quiet recently for similar reasons--the core devs are otherwise occupied--but there is a code sprint in a few weeks where we hope to tackle some of the major issues needed to make the high-level interface usable. I think at that point we will see the commits pick up again and have a much better idea of the future of VisPy.

4. My personal long-term plan is to continue with pyqtgraph and eventually begin incorporating components from vispy to allow pyqtgraph to make use of the GPU. I would love to hear thoughts about which use cases (current or future) are _not_ being met. Collectively, we are the ones who get to decide where (and whether) these projects go in the future. 

5. I am not aware of any other efforts toward high-performance plotting in Python. CA has put its weight behind Bokeh, which (I think) won't be appropriate for most of the pyqtgraph use cases. Anyone else have experience with other libraries?

Luke

--
You received this message because you are subscribed to the Google Groups "pyqtgraph" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyqtgraph+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyqtgraph/4c4d91e6-3339-4b2b-8b65-08af048acf40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[john lunzer]

Thank you for your quick and thorough response. Thank you for clarifying the lull in development of both projects mentioned. I understand about life getting in the way.

I agree that pyqtgraph feels quite mature and it is completely reasonable for development to slow down a bit. 

Despite not being what pyqtgraph is best used for I believe that the recently discovered ability for pyqtgraph to integrate into ipython/notebook is important to a larger community looking for a one-stop shop for graphing. Adding this ability may help give pyqtgraph more exposure. 

To that extent I believe having the ability to export video from animations would also appeal to a larger community and personally the lack of that exporting animations out of the box has kept me from sharing my work in pyqtgraph. It would be huge for me to have this.

I have only extensively used matplotlib and pyqtgraph. After I found pyqtgraph I stopped looking ;)

[Raphael Wimmer]

Hi,

Thank you, John, for asking about the current state and future of PyQtGraph. I was asking myself the same question today and found this thread :)

On Friday, February 27, 2015 at 5:04:11 PM UTC+1, Luke Campagnola wrote:

4. My personal long-term plan is to continue with pyqtgraph and eventually begin incorporating components from vispy to allow pyqtgraph to make use of the GPU. I would love to hear thoughts about which use cases (current or future) are _not_ being met. Collectively, we are the ones who get to decide where (and whether) these projects go in the future. 

 

I have used PyQtGraph in a university course on interaction techniques last year and plan to do this again this year. We primarily used the flowchart/node feature for building processing pipelines for sensor data: e.g., a WiimoteNode [1] receives accelerometer values from a Wiimote, these are processed in various subsequent nodes (buffering, moving average, FFT - to be implemented by the students) and then fed to a machine learning classifier.

I like that the nodes require students to implement modular filters and enable some simple visual programming.

However, debugging flowcharts could be significantly improved. It would be great to get warnings about incompatible data types between output and input terminals.

Also, it took me some digging through the source code to find out how to implement nodes that insert data into the flowchart (i.e. have multiple data sources in a flowchart that may also be added on the fly).

Luke, would extending the flowchart feature fit within your vision for PyQtGraph or would you prefer to keep it as simple as possible?

All the Best,

Raphael

[1] simplified version (to be extended by students): https://github.com/RaphaelWimmer/wiimote.py/blob/master/wiimote_node.py

[Luke Campagnola]

On Wed, Mar 11, 2015 at 5:24 PM, Raphael Wimmer <raphael...@ur.de> wrote:

Hi,

Thank you, John, for asking about the current state and future of PyQtGraph. I was asking myself the same question today and found this thread :)

On Friday, February 27, 2015 at 5:04:11 PM UTC+1, Luke Campagnola wrote:

4. My personal long-term plan is to continue with pyqtgraph and eventually begin incorporating components from vispy to allow pyqtgraph to make use of the GPU. I would love to hear thoughts about which use cases (current or future) are _not_ being met. Collectively, we are the ones who get to decide where (and whether) these projects go in the future. 

 

I have used PyQtGraph in a university course on interaction techniques last year and plan to do this again this year. We primarily used the flowchart/node feature for building processing pipelines for sensor data: e.g., a WiimoteNode [1] receives accelerometer values from a Wiimote, these are processed in various subsequent nodes (buffering, moving average, FFT - to be implemented by the students) and then fed to a machine learning classifier.

I like that the nodes require students to implement modular filters and enable some simple visual programming.

However, debugging flowcharts could be significantly improved. It would be great to get warnings about incompatible data types between output and input terminals.

That would be really nice; right now there is not much communication about data types between nodes except when the actual data propagates through the network. This could be tricky in some instances, though, because some terminals accept or generate a variety of different python types. Would you like to propose some changes? I would want it to 1) stay out of the way when it is not needed, 2) have minimal impact on performance, and 3) not complicate the API more than necessary.

There are probably many more ways we could make debugging more intuitive..

 

Also, it took me some digging through the source code to find out how to implement nodes that insert data into the flowchart (i.e. have multiple data sources in a flowchart that may also be added on the fly).

Luke, would extending the flowchart feature fit within your vision for PyQtGraph or would you prefer to keep it as simple as possible?

My take is that the flowchart system is a clunky mess of experimental code full of potential for improvements and powerful new features.  I would love to see it polished up, but it's not something I have time for personally (except when I need a new feature for my own work). I would be more likely to improve the documentation wherever you think it is needed, and would be happy to discuss strategies and ideas for improvement if you'd like to contribute.

Luke