So, surfing through the gr-qtgui source code, it’s not clear to me
whether the Qt widgets use OpenGL rendering or not.
If they do, then are the Qt widgets equally-likely to provoke some of
the horrible problems I’ve seen with the OpenGL in
WxWidgets used in Gnu Radio?
The OpenGL “eco-system” seems to break randomly, even for
apparently-correct applications, particularly when the DRM
is used in the X server, but only on certain hardware. This makes it
difficult to predict whether a given Gnu Radio application
will at some point fail, when run on hardware whose
OpenGL/DRM/whatever-the-heck has bugs.
I started looking at Qt (the GRC instance in particular) to see if I
could perhaps avoid the whole flakiness in the OpenGL
eco-system, but if Qt in turn uses OpenGL to render certain things,
then perhaps that’s not a wise thing to do?
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On Sun, Mar 27, 2011 at 1:37 AM, Marcus D. Leech [email protected]
wrote:
difficult to predict whether a given Gnu Radio application
will at some point fail, when run on hardware whose
OpenGL/DRM/whatever-the-heck has bugs.
I started looking at Qt (the GRC instance in particular) to see if I could
perhaps avoid the whole flakiness in the OpenGL
eco-system, but if Qt in turn uses OpenGL to render certain things, then
perhaps that’s not a wise thing to do?
Hi Marcus,
With the graphics framework available in recent Qt, the application
can decide at runtime whether to use Open GL rendering or not.
The qt-gui sink in GNU Radio uses Qwt so it is one level higher, still
the constructor has the parameter “use_openGL” which defaults to true:
qtgui_sink_c_sptr qtgui_make_sink_c (int fftsize, int wintype,
double fc=0, double bandwidth=1.0,
const std::string &name=“Spectrum Display”,
bool plotfreq=true, bool plotwaterfall=true,
bool plotwaterfall3d=true, bool plottime=true,
bool plotconst=true,
bool use_openGL=true,
QWidget *parent=NULL);
There is also a lower level opengl drawing surface that allows using
opengl API directly (as was the case with gr-wxgui) but that is not
used by gr-qtgui.
Alex
On 27.03.2011 10:10, Alexandru C. wrote:
If they do, then are the Qt widgets equally-likely to provoke some of the
horrible problems I’ve seen with the OpenGL in
WxWidgets used in Gnu Radio?
The OpenGL “eco-system” seems to break randomly, even for apparently-correct
applications, particularly when the DRM
is used in the X server, but only on certain hardware. This makes it
It did not work with a remote X server (Xming) on Windows XP.
(missing X extensions) So I had to switch it off.
eco-system, but if Qt in turn uses OpenGL to render certain things, then
perhaps that’s not a wise thing to do?
Is it needed for 2D acceleration? I didn’t see any 3D graphics in
Gnuradio.
I saw OpenGL in the waterfall plot code. Perhaps there are no standard
X functions for accelerated 2D shifting and stretching raster graphics,
right?
Btw, why are the spectral plots only stretched in X direction but not in
Y?
With the graphics framework available in recent Qt, the application
can decide at runtime whether to use Open GL rendering or not.
The qt-gui sink in GNU Radio uses Qwt so it is one level higher, still
the constructor has the parameter “use_openGL” which defaults to true:
qtgui_sink_c_sptr qtgui_make_sink_c (int fftsize, int wintype,
…
bool use_openGL=true,
QWidget *parent=NULL);
With wxgui this could be configured in ~/.gnuradio/config.conf:
[wxgui]
style=nongl
On 03/27/2011 03:01 AM, Josh B. wrote:
-Josh
And while we’re on the subject 
It would be good to be able to control update rate from GRC, right now,
it just uses the
default.
Multiple-traces in “scope”, and a “stripchart” mode would be good.
Actually without a multi-trace
strip-chart, I can’t consider migrating my current apps to the Qt-GUI
side.
How are multiple “tabs” (Notebook) supported from GRC on the Qt-GUI
side?
–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On 03/27/2011 07:27 AM, Marcus D. Leech wrote:
Multiple-traces in “scope”, and a “stripchart” mode would be good.
Actually without a multi-trace
strip-chart, I can’t consider migrating my current apps to the Qt-GUI
side.
Agreed. But who can we convince to implement these features.
How are multiple “tabs” (Notebook) supported from GRC on the Qt-GUI side?
Very similar to the notebook block w/ wx widgets. See the qtgui tab
widget block.
-Josh
On 03/27/2011 12:15 PM, Josh B. wrote:
Agreed. But who can we convince to implement these features.
You know I would, Josh. But I just started a new full-time job, and I
have very little
hacking time (double-plus 
). Whatever time I have, I dedicate to
the apps that
I’m working on (which, granted, could probably possibly support a
diversion into
“features I need from the platform”).
Very similar to the notebook block w/ wx widgets. See the qtgui tab
widget block.
-Josh
OK, found that. What are the semantics of the “GUI Hints”. You’ve
probably covered it in another thread. But
humour me, because I’m a crotchety old man with a migraine at the
moment
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org