I don't really care which GUI framework is used, just that it works.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:56:51 -0400
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
From: hilbert3...@gmail.com
To: mark.mccar...@live.co.uk
CC: discuss-gnuradio@gnu.org
One of the beauties of open-source software is that if you don't like the way
something works, or think it should be
enhanced, you can take care of that yourself, and, hopefully, share the
results with the community.
If you don't have the necessary skils to do so, then you make your desires
known, and hope that the developers
will, at some point, consider your needs, and decide whether it's worth
implementing them, and putting said
implementation on the schedule.
I think Marcus had previously stated that the GUI elements in Gnu Radio itself
were primarily designed as an aid
to instrumenting and debugging flow-graphs, and that only secondarily are
they useful for building real applications.
It would be useful for Tom to chime in here about the features of the QtGUI
stuff in "next". Nobody is actively
working to make the wxGUI side of things "lovely" at this point, because
energy is going into, as far as I know,
the QtGUI side.
On Thu, May 16, 2013 at 1:36 PM, Mark McCarron <mark.mccar...@live.co.uk> wrote:
Marcus,
Accurate output is great when doing analysis, but if you just want to create a
quick interface that will allow you to see a little more detail, then
overlapping or duplicating the stream is fine. The error in the output is
always within a given tolerance and that can be suitable for a lot of
applications. By no means am I suggesting to eliminate the accurate GUI
elements, just that an alternative should be offered.
I tested your sample and that works fine on my machine. I have updated it to a
refresh rate of 30 and this is when it becomes unresponsive. I ran perfmon and
the resources seem fine, but I do see a massive spike
in page faults and transition faults when executing a flow graph. That,
in itself may not be an issues, but I have checked all the usual
bottlenecks and they are barely being touched. I'm running the latest Windows
build of this on a quad core Win2012 server with 16GB ram.
It seems like a bug in the build.
Regards,
Mark McCarron
Date: Thu, 16 May 2013 13:02:09 -0400
From: mle...@ripnet.com
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
On 05/16/2013 12:41 PM, Mark McCarron wrote:
Marcus,
Thanks for highlighting the limitations of the current
implementation. It explains a lot. Personally, I would like to
see a little more emphasis on useful GUI elements, not just
accurate GUI elements.
So, you'd rather see fast updates of near-complete-nonsense, than
slow updates of accurate data? :) :)
In regards to the WX GUI FFT window not responding. I have
tested it with a very simple flow-graph. A USRP source and the
WX FFT GUI block. If the settings are at 4096@15fps, it works
fine, try anything higher and the windows greys out. So, I
don't really see where the issue is.
Works for me with the latest Gnu Radio on F14.
You may just be running out of computational steam in Python land,
since the wxGUI FFT sink does waaaay too much of its "stuff" in
Python land.
Python runs up to about 100 times slower than equivalent native
code.
I've attached a simple test that works just fine here.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
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
--
Hilbert (Godamn) Transform
hilbert3...@gmail.com
Purveyor of fine Hilbert (Godamn) Transforms since 2013
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
