Is there a frame rate limit?

[Christopher Cope]

I didn't know if I should try to get in touch with you via the AeroQuad forums or here, but I figured I'd get a faster answer here. Is there some sort of frame rate limit with pyqtgraph? I've been working on adapting everything to a benchmark script that doesn't directly interact with any of the AeroQuad code and the one big thing I've noticed between yours and Chaco's is that the frame rate is proportional to the window size with Chaco, but constant with yours. For large windows, 1280x800, this actually gives you ~2 FPS advantage (22 FPS) over Chaco; however, for smaller windows such as with the default AeroQuad window size, it works to your disadvantage where you continue to get ~24 FPS whereas Chaco takes the lead with ~32 FPS. This trend continues as the window size decreases, eventually having Chaco reach triple digits while you're still chugging along (not necessarily in a bad way) at ~24 FPS. It should be noted that this is with simulated data, not from the serial port. Thanks!

[Luke Campagnola]

On Wed, Jan 2, 2013 at 8:53 PM, Christopher Cope <shado...@gmail.com> wrote:

I didn't know if I should try to get in touch with you via the AeroQuad forums or here, but I figured I'd get a faster answer here. Is there some sort of frame rate limit with pyqtgraph? I've been working on adapting everything to a benchmark script that doesn't directly interact with any of the AeroQuad code and the one big thing I've noticed between yours and Chaco's is that the frame rate is proportional to the window size with Chaco, but constant with yours. For large windows, 1280x800, this actually gives you ~2 FPS advantage (22 FPS) over Chaco; however, for smaller windows such as with the default AeroQuad window size, it works to your disadvantage where you continue to get ~24 FPS whereas Chaco takes the lead with ~32 FPS. This trend continues as the window size decreases, eventually having Chaco reach triple digits while you're still chugging along (not necessarily in a bad way) at ~24 FPS. It should be noted that this is with simulated data, not from the serial port. Thanks! 

There is no frame limiter explicitly built in to pyqtgraph. However, Qt's GraphicsView is a very complex system with a lot of optimization built in, which means that benchmarks can at times be a bit difficult to understand. The exact behavior depends on what operating system you have, whether you are using OpenGL as the backend for GraphicsView, which Qt graphics system you are using (see QApplication.setGraphicsSystem), whether you have a compositing window manager, etc. 

On my system, the "Line plot update" example (single plot, 5k points) runs at 30fps full-screen (1920x1200), and 220fps very small.  If I change this to plot 5 different curves with 1000 points each, the minimum is still 30fps, but the maximum drops down to 60fps (this was a surprise to me and actually indicates a possible avenue to speed things up--I'll let you know if that leads anywhere). This is still not as flat as your results, though, which suggests to me either an OS / environmental difference or something related to the testing code itself. 

Could you tell me:  

 - What OS are you using?

 - What rates do you get from the "Line Plot update" example? (including at different window sizes)

 - What happens if you put pg.QtGui.QApplication.setGraphicsSystem('raster') at the beginning of your program?

 

Thanks!

Luke

[Christopher Cope]

First, to answer your questions, perhaps more verbosely than requested, but hey, more information can't be bad, right…

• What OS are you using?
  

• Hardware
• MacBook Pro: 15-inch, Mid 2009
• Processor: 2.66 GHz Intel Core 2 Duo
• Memory: 8 GB 1067 MHz DDR3
• Graphics: NVIDIA GeForce 9400M 256 MB
• Software (All 64-bit)
• Operating System: OS X 10.8.2
• Qt: 4.8.2
• Python: 2.7.3
• PySide: 1.1.1
• NumPy: 1.6.2
• pyqtgraph: 0.9.3
• What rates do you get from the "Line Plot update" example (including at different window sizes)?
  
• Fullscreen Window (~ 1440x900): ~ 75 FPS
• Default Window (~ 800x800): ~ 111 FPS
• Tiny Window (~ 100x100): ~ 130 FPS

• What happens if you put pg.QtGui.QApplication.setGraphicsSystem('raster') at the beginning of your program?
  

• Frame rates actually drop by ~4 FPS. For yours, 'native' gets the best frame rate. For Chaco, 'native' or 'opengl' get the best frame rate with 'opengl' occasionally taking the lead by ~1-2 FPS.

Since I'm going to eventually post the results to the AeroQuad forums, I'll let you have a sneak peek at what I'm currently doing to try and benchmark things. The code is currently available at: https://gist.github.com/4448257.

The two things I've focused on while designing this are the minimization of any library specific code and the mimicry of what the final AeroQuad application will require. The latter is the reason I've chosen to do nine plots with grids, automatically adjusting axis labels, and antialiasing. Obviously, this is also probably going to be the most performance intensive setup, but if one of the libraries can handle it, there's no sense in decreasing the requirements - that library will simply be the "winner". In addition, if it can handle it, then chances are it would probably still outperform the other libraries if those features were disabled (I've done a few tests to verify this).

Obviously, I'm not an expert on your library, but I did try to imitate the benchmark you'd previously posted, simply switching out anything that could be replaced by something any potential graphing library could use. On an unrelated note, you don't yet see matplotlib there since although I did get it working in the configurator, it was rather excruciating to do so and I've yet to get the axis labels to automatically adjust with it so I'm not sure if I want to endure the pain once more to add it to the benchmark, especially since pyqtgraph and Chaco look to have better performance and easier setup anyway.

[Luke Campagnola]

On Thu, Jan 3, 2013 at 6:09 PM, Christopher Cope <shado...@gmail.com> wrote:

Since I'm going to eventually post the results to the AeroQuad forums, I'll let you have a sneak peek at what I'm currently doing to try and benchmark things. The code is currently available at: https://gist.github.com/4448257.

This looks good, and it appears that performance on OSX behaves similarly to linux. 

Some notes: 

 - I noticed you're using time.clock(). I'm not sure how this works on OSX, but on linux this only has a 10ms resolution, which can significantly affect the results (made a difference of about -5fps for us).

 - Rather than using enableAutoRange, just call plot.autoRange() after you have finished updating all of your plots. This speeds things up considerably since the view would otherwise need to calculate new boundaries once after each plot line is updated. There might be a way to resolve this on my end, but I haven't worked one out yet..

 - when you call PlotItem.plot(), this generates a PlotDataItem, which is basically a wrapper around a PlotCurveItem and ScatterPlotItem. Since you don't need to draw points, you can remove a little bit of processing overhead by creating the PlotCurveItem manualy:

    # instead of this:

    curve = plt.plot(data, pen=...)

    # do this:

    curve = pg.PlotCurveItem(data, pen=...)

    plt.addItem(curve)

    

Luke