how would you do this (animated bargraph) (Neal Becker)

Neal,

I do something similar to this where data that I'm plotting in a 2D line plot comes from a UDP socket and some memory mapped files. To accomplish the live updating I have a mix of your #2 and #3. I have a main GUI thread that displays the plots, then I have a second thread that gets data from a python generator and signals the GUI thread when that new data has arrived. Inside the generator is where I have socket communications and select calls. Hope this helps.

-Dave

···

On 9/30/11 9:10 AM, matplotlib-users-request@lists.sourceforge.net wrote:

Message: 4
Date: Fri, 30 Sep 2011 07:37:49 -0400
From: Neal Becker<ndbecker2@...287...>
Subject: [Matplotlib-users] how would you do this (animated bargraph)
To:matplotlib-users@lists.sourceforge.net
Message-ID:<j649me$ug4$1@...3002...>
Content-Type: text/plain; charset="ISO-8859-1"

I just put together an animated bargraph to show results from a realtime
process.

I used this as an example:
http://matplotlib.sourceforge.net/examples/animation/animation_blit_qt4.html

The tricky part for me was that in the original design, there was a realtime
process running. I have to write some information to my hardware (at a rate of
about 1/360ms). To do this, I have a kernel driver that uses 'read' to tell the
user space when an interrupt has occurred, which is when the user space should
write new information to the hardware.

So I don't know how or if this could be hooked into qt event processing. Just
for a quick-and-dirty demo, I just removed the realtime processing from the
user-space and put it in the kernel driver, so now my bargraph display can
simply update on a periodic timer, and the userspace code has no realtime
requirement. But this is just a kludge.

So I wonder how other's would solve this? I'm thinking it would be either:

1) multi-process
2) multi-thread
3) 1 process, but somehow hook my realtime events into qt's event loop.

For #3, my device driver has a filedescriptor, that could use select to detect
the interrupt (rather than blocking read call).

#1 and #2 seem complicated.