On Sun, May 8, 2011 at 10:40 PM, Stefan Gofferje <stefan.goffe...@gmx.de>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/08/2011 11:50 PM, Marcus D. Leech wrote: > > I discovered rather by accident that if my FFT sinks had averaging > > turned *OFF*, that even at > > modest input bandwidths on my dual-centrino laptop, they'd get wedged, > > even at relatively-low > > FFT frame rates (3 for example). But turn on averaging, and the > > systems resources required > > were reduced to the point that the display could support FFT display. > > I think this says something > > about how (in) efficient OpenGL is about rendering even simple 2D > > objects that change dynamically. > > I have similar observations but without any hardware. The WX FFT totally > locks my Athlon 64 3800+, when displaying. > > Just signal source -> FFT sink. > > BUT - only the WX FFT. The QT FFT seems rather reasonable in performance > demands. > Stefan, Are you saying you're using a gr_sig_source straight into the FFT sink? You should probably put a gr_throttle block in there since you have nothing else rate-limiting the flowgraph. It's not a surprise that the Qt sinks are more efficient, though. The wxPython has a lot of stuff implemented directly in Python where as the QtGui is almost entirely done in C++. Tom > - -- > (o_ Stefan Gofferje | SCLT, MCP, CCSA > //\ Reg'd Linux User #247167 | VCP #2263 > V_/_ Heckler & Koch - the original point and click interface > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (GNU/Linux) > > iEYEARECAAYFAk3HDcUACgkQbQKZlCdPOMMgBgCdFZnkjXIKmsiEVI8JmrsjHRX5 > AYwAn1YT+cl9SrsG8Z/iuZvrsaoxQC7q > =AHue > -----END PGP SIGNATURE----- > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
