Hi,
Apps with one graph (say “usrp_fft.py -f 103.3”) draw a nice plot that
looks like it’s updated at approx 10Hz. However, the controls (sliders,
etc) do not respond and do not redraw if I move the window off then back
onto the page.
Apps with two plots only update one plot at a time at 10Hz for 3
seconds, then switch to update the other round-robin style. Ditto for
three apps.
wfm apps place fine audio.
I’m running SVN revision 4050 on a dual processor 2.4Ghz machine. The
CPU is barely used. Every once in a while python spikes to 30% of one
of the CPUs, but on average it’s near zero. My machine does not seem
sluggish. The hard drive is not active.
My c++ wxWidgets apps behave like this when I use OnIdle to perform
“infinite loop” processing with a periodic wxSleep() calls.
Anyone know why I get this behavior?
Thanks,
Chris
Chris S. wrote:
Apps with one graph (say “usrp_fft.py -f 103.3”) draw a nice plot that
looks like it’s updated at approx 10Hz. However, the controls (sliders,
etc) do not respond and do not redraw if I move the window off then back
onto the page.
Update: this only happens when I run the app remotely (ssh -X). It’s
not an issue afterall, I’ll just run locally for now.
Chris
Update: this only happens when I run the app remotely (ssh -X).
I have this issue, too. It appears that either the gnuradio app itself
or the toolkit that it’s using (wxPython?) has some server-dependent
code. I get no errors when running locally; some errors when running on
X-Win32 from Starnet on Windows over an SSH tunnel; and still more
errors when I try to run against Xvnc under NetBSD.
/jordan
On Mon, Dec 04, 2006 at 04:08:59PM -0800, Jordan H. wrote:
Update: this only happens when I run the app remotely (ssh -X).
I have this issue, too. It appears that either the gnuradio app itself
or the toolkit that it’s using (wxPython?) has some server-dependent
code. I get no errors when running locally; some errors when running on
X-Win32 from Starnet on Windows over an SSH tunnel; and still more
errors when I try to run against Xvnc under NetBSD.
/jordan
Try using:
$ ssh -X -Y
it may help.
Eric
I get no errors when running locally; some errors when running on
X-Win32 from Starnet on Windows over an SSH tunnel; and still more
errors when I try to run against Xvnc under NetBSD.
Try using:
$ ssh -X -Y
-Y is an authorization hack, but X over ssh already works great (xterm,
et al work fine). So it’s not that. I get the same thing the original
poster gets: apps work fine on the console; graph gets displayed, can’t
manipulate sliders, etc. over SSH. But: the window does come up; it’s
just like the focus is away from that window.
Under Xvnc, I get this error:
Error: Cairo 1.2.6 does not yet support the requested image format:
Depth: 8
Alpha mask: 0x00000000
Red mask: 0x00000007
Green mask: 0x00000038
Blue mask: 0x000000c0
Please file an enhancement request (quoting the above) at:
http://bugs.freedesktop.org/enter_bug.cgi?product=cairo
assertion “NOT_REACHED” failed: file “cairo-image-surface.c”, line 201,
function “_cairo_format_from_pixman_format”
Abort trap (core dumped)
So I’m gussing it’s different X server implementations that are getting
screwed up here.
/jordan
Chris S. wrote:
Chris S. wrote:
Update: this only happens when I run the app remotely (ssh -X). It’s
not an issue afterall, I’ll just run locally for now.
I can recreate this problem locally (not over SSH) by running the
usrp_wfm_rx example and enabling drawing of audio output (“if 0” -> “if
1”)
Chris
On Mon, Dec 04, 2006 at 09:41:57PM -0800, Chris S. wrote:
Chris
I’m beginning to sound like a broken record, but it would be really
great if somebody would fix the poor performance of the wxPython
plotting.
Problems get fixed when somebody is willing to work on them, and not
one second before. If it bugs you, please help out and fix it.
If anybody is waiting for me to fix this particular problem, you’re
going to be waiting a long time. I just throw faster h/w at it 
Eric
I am working on the plotting widgets every chance I get. At the moment
this is not at the top of my list but I am making progress. I have run
into one problem with wxWidgets that someone might be able to answer:
Using the DrawRotatedText function from the wxDC class seems to produce
a clipped, mangled looking string. Has anyone seen this and is there a
solution? I have seen a side note in the docs about using TrueType fonts
with Windows, but I am running Linux and tried all of the font families
with no luck.
The USRP was given a green light at work so as soon as I get a few
smaller projects wrapped up, this will get my full concentration. At
that point, I will have an optimized C++ widget and will make every
effort to make it portable and comply with the GNURadio standards.
Thanks,
Ryan
On Tue, Dec 05, 2006 at 10:56:59AM -0400, Ryan Seal wrote:
I am working on the plotting widgets every chance I get. At the moment
this is not at the top of my list but I am making progress.
Very good. Glad to hear it!
I have run into one problem with wxWidgets that someone might be
able to answer:
Using the DrawRotatedText function from the wxDC class seems to produce
a clipped, mangled looking string. Has anyone seen this and is there a
solution? I have seen a side note in the docs about using TrueType fonts
with Windows, but I am running Linux and tried all of the font families
with no luck.
Sorry, I’m not sure about that. I assume there are examples somewhere
in the wxWidgets distribution. How do they handle rotated text?
The USRP was given a green light at work so as soon as I get a few
smaller projects wrapped up, this will get my full concentration. At
that point, I will have an optimized C++ widget and will make every
effort to make it portable and comply with the GNURadio standards.
That’s great news. Thanks!
Eric