Graphics for a waveform viewer

ocho_aces has asked for the wisdom of the Perl Monks concerning the following question:

Hi all, I want to create a Perl waveform/timing diagram viewer for digital waveforms. There are various file formats that I can read to get the timing information and I can do that already.

However, what I need help in is deciding the best/easiest approach to generate the graphics. Right now I know very little about graphics generation and only a little about GUI programming.

My plan is to build the waveform viewer using wxPerl for the GUI framework. The rest, I'm afraid I'm still a bit lost on. Would using a vector graphics approach work? I'm thinking I could translate the timing data format (e.g. VCD format) into vector graphics format without too much trouble. I figure this would make zooming in and out less painful.

However, down the road there is a chance I'd want to generate live data streams on the screen (say if I'm collecting live data from some electronics). Would a vector graphics approach still be a good solution?

Any tips on the most appropriate libraries or modules and the reasons for those I'd love to hear about. Any tips on things to avoid would also be great. And any tips in general would also be appreciated.

Regards,
Jose

Comment on Graphics for a waveform viewer

Replies are listed 'Best First'.
Re: Graphics for a waveform viewer by eye (Chaplain) on Dec 07, 2008 at 09:38 UTC
This is outside my personal experience, so YMMV. I think there is a lot to be said for using vector graphics in such an endeavor. Specifically, I think SVG is starting to show signs of maturity. SVG is an XML application, so you have a broad range of tools available to handle the files, including the SVG module. That said, how wedded are you to using wxPerl for your GUI? While there is an add-on for rendering SVG in wx (wxSVG), it does not seem quite as mature as wx (nor does it appear to have Perl bindings). Another approach would be to render your SVG in a browser. Some of the newer browsers include native support for SVG. This could potentially let you focus on building the SVG and let "someone else" handle the rendering. The alternative to vector graphics is going to be some kind of rasterization (e.g., ImageMagick). In this case, wxPerl should be able to satisfy your needs, though your program will become more of a broker between external components.	[reply]
Re: Graphics for a waveform viewer by zentara (Cardinal) on Dec 07, 2008 at 13:51 UTC
From my experience with Gtk2 (upon which Wx can be built on some systems), svg will be very slow. However, if you use one of the modern canvas type widgets, ( I don't know Wx), like the Gnome2::Canvas or the Goo::Canvas, you can do pixel zooming quite easily. See Goo::Canvas Graphing demo Gnome2::Canvas Scribble with Image and Tk Realtime data aquisition for some non-Wx graphing ideas, that you may use with Wx. I'm not really a human, but I play one on earth Remember How Lucky You Are	[reply]
Re^2: Graphics for a waveform viewer by gwadej (Chaplain) on Dec 08, 2008 at 00:02 UTC
The speed of SVG as a graphics format depends greatly on the viewer and what kinds of changes you are making. I'm working on a project to measure some of the current viewers to determine reasonable estimates of what update rate they can maintain. I have run non-trivial SVG applications driven by scripting on the order of 30-50 updates per second on multiple viewers. Unfortunately, the feasibility of using SVG for this is a function of what update frequency you need and the complexity of your display (mostly the dynamic parts). G. Wade	[reply]
Re: Graphics for a waveform viewer by graff (Chancellor) on Dec 08, 2008 at 04:43 UTC
I would go with zentara's suggestion to just do normal xy plotting on a canvas widget. "Good old Perl/Tk" might a tad slow if you have lots of data points per display, but there's Inline::C and clever tricks for data reduction in case you are trying to put (say) pu to 200,000 sample points onto a time line that's only 1000 pixels wide. But you already plan on using something newer than that, and speed probably won't be much of an issue. As for this point: I figure {vector graphics} would make zooming in and out less painful. In terms of time-series waveform data, it's fairly typical to want to control the vertical and horizontal zoom independently -- e.g. zoom in or out on just the y-axis scale according to the amplitude of (the portion of) the waveform that happens to be on display at the moment, or zoom in or out on just the x-axis scale in order to see either more detail or more data in the window. Maybe vector graphics does this very elegantly, but if your xy-plot rendering is reasonably fast, it's just as good to redraw however many dots or line segments are needed to fill a 1000-pixel-wide display of a time series.	[reply]
Re: Graphics for a waveform viewer by zentara (Cardinal) on Dec 08, 2008 at 15:08 UTC
There is gtkdatabox I hesitate to mention it, because there is a Perl module only for it's earliest version. Google for "Gtk2-Databox" for links to the old versions. The old versions work just fine, and have many features that you request. Possibly, you could pick up on the module, and port the latest gtkdatabox to Perl :-). If you want to avoid the Canvas type widgets, want to use Perl, and SVG, you might want to go with a DrawingArea. See Drawing with Perl/Gtk2 Special handling is required with a DrawingArea, as opposed to a canvas type widget, because you must deal with the expose event. I'm not really a human, but I play one on earth Remember How Lucky You Are	[reply]
Re: Graphics for a waveform viewer by ocho_aces (Initiate) on Dec 10, 2008 at 00:43 UTC
I appreciate all your replies and thank you for taking the time to respond. I still like the SVG idea, but I have come up with a couple other requirements that I think will rule it out for now. I still need to do a little more research into this and will be looking at the Goo::Canvas, Gnome2::Canvas, as well as Image::Magick to see which one of those I think will best work. Then it will be off to create a very crude first try at a simple drawing. I'm sure I'll have more questions as I progress. Thanks again for your input!! Regards, Jose	[reply]