Question

I’m working on creating a headless console application in QT4 that does some OpenGL rendering and then ships the result out across the network via a websocket. I have all of the rendering and network code running (assuming that I have a GUI), but I am having some trouble transitioning to a headless application. Is it possible to create a QGLContext without having a window?

Reading on the web hasn’t turned up much, but from what I have gathered you can create a QGLPixelBuffer which is a valid QPaintDevice. It seems to create its own private QGLContext that it uses for hardware accelerated drawing. The problem that I am having with this route is that I need access to it’s underlying QGLContext so that I can share it with another thread (network thread for fast DMA texture transfers out of the rendered scene). Included below is a small prototype. Any ideas?

Application.h

/**
@file
@author     Nikolaus Karpinsky
*/

#ifndef _APPLICATION_H_
#define _APPLICATION_H_

#include <QCoreApplication>
#include <QTimer>

#include "MainController.h"

#endif  // _APPLICATION_H_

Application.cpp

#include "Application.h"

int main(int argc, char **argv)
{
//  Setup our console application with an event loop
QCoreApplication app(argc, argv);

//  Create and initialize our controller
MainController controller;
controller.Init();
QObject::connect(&controller, SIGNAL( Finished() ), &app, SLOT( quit() ), Qt::QueuedConnection);

//  This will put start on top of the event loop
QTimer::singleShot(0, &controller, SLOT( Start() ));

// Finally start up the event loop
return app.exec(); 
}

MainController.h

/**
 @file
 @author        Nikolaus Karpinsky
 */

#ifndef _MAIN_CONTROLLER_H_
#define _MAIN_CONTROLLER_H_

#include <QObject>
#include <QGLWidget>
#include <QGLPixelBuffer>
#include <QGLFramebufferObject>
#include <memory>

using namespace std;

class MainController : public QObject
{
  Q_OBJECT

private:
  unqiue_ptr<QGLPixelBuffer> m_mainBuffer;
  //unique_ptr<QGLContext> m_mainContext;

public:
  MainController();
  void Init(void);

public slots:
  void Start(void);
  void Close(void);

signals:
  void Finished(void);
};

#endif  // _MAIN_CONTROLLER_H_

MainController.cpp

#include "MainController.h"

MainController::MainController() : QObject()
{ }

void MainController::Init(void)
{
  m_mainBuffer = unique_ptr<QGLPixelBuffer>(new QGLPixelBuffer(800, 600));
  bool has      = buffer->hasOpenGLPbuffers();
  bool current  = buffer->makeCurrent();
  bool valid    = buffer->isValid();

  //  Now I need to get access to the context to share it with additional threads
  // m_mainContext = unique_ptr<QGLContext>(new QGLContext(buffer.getContext()));
}

void MainController::Start(void)
{
}

void MainController::Close(void)
{
  //  This will tell the event loop that we are done and close the app
  emit( Finished() );
}

Answer 1

Is it possible to create a QGLContext without having a window?

Yes, but there is a catch…

Reading on the web hasn’t turned up much, but from what I have gathered you can create a QGLPixelBuffer which is a valid QPaintDevice.

Yes, but that PBuffer still needs to talk to the GPU. And in Linux the usual way to talk to the GPU is through the X server. So you actually need an X server, using the GPUs drivers, to be launched and the active VT so that a PBuffer can work on the GPU.

Hopefully there will be a new ABI/API to GPUs soon, that allows you to create offscreen render contexts on a GPU without having an X server around.

The problem that I am having with this route is that I need access to it’s underlying QGLContext so that I can share it with another thread (network thread for fast DMA texture transfers out of the rendered scene).

Unfortunately the Qt developers have only limited knowledge about OpenGL, as it seems. Several things that are perfectly possible with OpenGL and well specified are not possible with Qt for no apparent reason. For example you can have an arbitrary number of contexts using a single drawable. But you can also use single context on an arbitrary number of (compatible) drawables by rebinding it. Neither is supported by Qt and a clear design flaw. I’m struggling with this myself right now.