Re: [Discuss-gnuradio] qtgui sink - flakiness at deconstruction time

[Marcus D. Leech]

On 03/27/2011 12:28 PM, Tom Rondeau wrote:
> Yes, I've known about this issue for a while but decided to ignore it 
> since it didn't seem to be harming anyone (and I had no idea what was 
> causing it). Since it's actually starting to affect people, I'll look 
> into it.
>
> Mike Cornelius has made some big changes to the qtgui framework that I 
> have yet to find the time to work on merging it. But today seems like 
> a good a day as any to dive in and start hammering away at these problems.
>
> Also, from another thread, I agree that being able to put multiply 
> streams into a single scope plot would be really useful. I'll see what 
> I can do about that, too, but that's going to take some serious 
> surgery since all of the plots (fft, waterfall, scope, constellation, 
> etc.) are generated at the same time.
Yeah, the "monolith" approach that's currently used for the Qt-GUI 
"sink" is a bit awkward for making changes.

My main reason for going down this path is to hopefully avoid some of 
the OpenGL flakiness, the somewhat-better performance, and a
  (subjective) nice "look" to the Qt GUI widgets as compared to the 
WxPython ones.

One of the "hacks" I was thinking of implementing was that if the user 
had selected *only* the time-domain plot, and the sample-rate was
  "low", then it would automatically do a strip-chart type display.  
But that was simply a way to avoid changing the API in any way.

Strip-chart is fairly easy to implement as a "preprocessor" for the 
regular time-domain display.  Instead of waiting for a buffers-worth of
  samples before calling the time-domain plotter, you shift all the 
samples in the buffer over by one (dropping one off the end), then
  insert the fresh sample at the beginning, then call the plotter.  The 
difference is that the plotter gets called on every sample addition, instead
  of every DISPLAY-SIZE samples.  Obviously, you only want to do this 
for fairly low-rate data, but strip-charts tend to be used for
  low-data-rate stuff, a few samples per second is the usual maximum.

The time-domain plotter already supports separate "pens" for I and Q, so 
adding more pens shouldn't be that huge a deal at the level
  of the plotter.  But the "work" function needs to be made aware of 
potentially more than 1 input data stream.






--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org