views:

2058

answers:

9

I am looking for a C++ library or component which would ideally be cross-platform, but will first only be needed for Win32.

The requirements are:

  • one to 10 updates per second
  • good documentation and samples
  • easy to use
  • cross platform (optional)

Basically we have some data derived from financial market data feeds and we do some calculations on it. We then want to visualize the derived data in some the form of graphs/plot. We'll most likely have three "lines" or "streams" of data that we want to plot in "real time" or near real-time.

I want to be able to tell some graph object that I have another x,y coordinate and to continue drawing the line graph from the last point. This is just a stream, and I want to keep some window of time (last minute or so of samples)

Free (As in beer and as in speech) would be great, but we can spend money for licenses as well. We would distribute the resulting executable.


EDIT:

The updates will probably be aggregated, so the UI will refresh with the latest batch of data since the last time delta. So this will be refreshed maybe once or two times per second. That update rate for a UI I originally mentioned is stupid. The data updates are on the order of thousands per second, but the UI will not need to have that resolution.

A: 

ROOT could probably meet your needs, but it is a pretty heavy package, and tends to want to have everything its own way...

dmckee
+1  A: 

RRDtool is pretty good. Don't know anything about its performance under heavy load though.

Nikolai N Fetissov
Looks nice. Can I do "real-time" plotting with this? or is the graphing done after? We want to see a moving right edge when new values are obtained.
Tim
I think so. Here's for example what one can get out of OpenBSD/PF with it: http://www.benzedrine.cx/pfstat.html
Nikolai N Fetissov
+2  A: 

QT has a complete 2D plotting framework via QPainter. As a backend it can use the either native graphics or OpenGL.
The performance you get will be dependent on the complexity of what you draw. I'm pretty sure though that hundreds of frames per seconds is usually not something you can reasonably expect. most displays can't physically refresh more than 200 times per second (200Hz) so updating more frequently than that is probably a waste of time.

shoosh
+2  A: 

PLplot should fit perfectly for your purposes.

nhaa123
A: 

You should try:

www.oscilloscope-lib.com

+1  A: 

We wrote our own. It's not particularly difficult. We could handle up to 10 inputs at 40 fps at nearly fullscreen or have 5 mini graphs with about 30 inputs across them all at 20 fps.

graham.reeds
+1  A: 

As for the performance part, it seems to do with three things:

  1. Data update rate (the rate at which there could have been a visible change to the image taking into account its crop, zoom, etc)
  2. Image update rate ("actual" frame rate)
  3. Hardware + software capability to produce the frame rate you target (if your graphs are rather simple (i.e. line), software rendering (even hand-coded in winApi or, better, some Borland Builder) will be enough, otherwise you can turn to openGL (quite easily done with Qt) or directX)

As has already been mentioned in other answers the image and data update rates should not be strictly equal.

Human eye percieves a previously dynamic picture as "frozen" for a bit of time, if it has not changed for 1/24th of second (remember the effect of the 25th frame -- it's not noticed consciously). Some software and camera video codecs even use a frame rate below 20 fps (frames per second). So you may target an fps of 20 -- 25.

I personally recommend looking at Qt (as shoosh suggests). It's free (LGPL), nice to work with (not buggy, with great (possibly greatest) help system, very cleanly designed), writing a graphing class you need (subclassing it from QWidget or smth) seems to be doable in 1-2 days max. The only (possible) substantial drawback is the size of .dll's needed to be shipped with the app -- about several MB.

Hope this helps, and forgive my english.

UPDATE: You may also look at LiveGraph at http://www.live-graph.org/index.html, which may not be sufficiently customizable for your task, but philosophically seems to be that very thing.

mlvljr
thanks for the live-graph update. I am going to look at that carefully - it might be sufficient for our demos.
Tim
you're always welcome!
mlvljr
A: 

TAU is, to quote dmckee "pretty heavy" also, heavy meaning there is a considerable amount of architechture and domain specific technology to pick up unless you have a big background in profiling. It seems TAU is a fair amount more developed than some of these other options, providing many API for static/dynamic binary or source instrumentation, Visualization (this one is a bit old, but kiviat diagrams are quite dynamic and are ment to depect highly performance sensative systems to help find and avoid blocking operations.

You can use one part or another, it's not an all or nothing solution.

RandomNickName42
A: 

I'm pretty happy with National Instrument's LabWindows/CVI. It provides most of the same nifty graphing widgets as Labview, but you connect them with a farily clean API instead of the tedious Labview method of dragging virtual wires around a "visual" layout. We've used it to capture and plot incoming data @10Khz. The only downside is the price, which starts at $1300 and goes up.

AShelly