Use of OpenGL in gr-qtgui

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 :slight_smile:

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. :slight_smile:

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. :slight_smile:

You know I would, Josh. But I just started a new full-time job, and I
have very little
hacking time (double-plus :frowning: ). 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 :slight_smile:


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs