[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] qtgui sink - flakiness at deconstruction time
From: |
Marcus D. Leech |
Subject: |
Re: [Discuss-gnuradio] qtgui sink - flakiness at deconstruction time |
Date: |
Sun, 27 Mar 2011 12:48:50 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 |
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