On Sun, Feb 5, 2012 at 5:07 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
> On 02/05/2012 04:44 PM, Marcus D. Leech wrote: > >> On 02/05/2012 04:08 PM, Tom Rondeau wrote: >> >> So, what if it was your *own* commit that seemed to be causing a problem? >> Wouldn't that be embarrassing? I think so :-( :-( >> >> commit 2a2411a598c222e2ef82b857c0b53e**0a9d1daf3f >> Author: Marcus Leech <mle...@ripnet.com> >> Date: Sun Jan 15 23:49:52 2012 -0500 >> >> core: fix for off-by-one issue in strip chart. Increases buffer size >> for longer displays. >> >> >> >> I have no idea why this should be a problem, the buffer-shifting for >> stripchart mode is all done on the C++ side, and the updates are >> done at a fairly lazy rate (a few Hz). So it's probably an issue on the >> Python side with bigger plot buffers. Perhaps there's some kind of >> N**2 scaling ugliness going on that wasn't immediately obvious to me >> when I did that patch. >> >> I think ultimately, the plotting stuff has to move so that most of the >> computational stuff is done in C++ land, with only the thinnest pieces >> done on the Python side. >> >> >> >> >> So performance degradation seems to scale with the size of > OUTPUT_RECORD_SIZE in gr_oscope_guts.cc. This basically determines how > big the messages are that are sent along to the plotter routines in > Python, but the STRIPCHART routine uses it to store the strip-chart > samples in. > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > It sounds like we need someone to work on a strip-chart functionality for the qtgui sinks. They do everything in C++ land, so we could optimize there more easily. In other news, glad you found the problem. What do you want to do about it in the meantime, since it's your code, and I think you're the primary user of the oscope under these conditions. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
