David Hoese wrote:
> 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.
Haven't tried it, but I did notice QSocketNotifier, which sounds like it may be
what I need if I want to hook into qt event loop to implement as single-thread,
> On 9/30/11 9:10 AM,
>> Message: 4
>> Date: Fri, 30 Sep 2011 07:37:49 -0400
>> From: Neal Becker<ndbecker2@...>
>> Subject: [Matplotlib-users] how would you do this (animated bargraph)
>> Content-Type: text/plain; charset="ISO-8859-1"
>> I just put together an animated bargraph to show results from a realtime
>> I used this as an example:
>> 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
>> 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.