0

I am using gitlab-ci-runner to automatically test a desktop Qt/OpenGL application on every commit. On Windows 8, the application is executed by a system service installed with gitlab-ci-runner, hence it is run "hidden", i.e. on no visible desktop. All the UI modules initialize and run anyway, except the OpenGL module, which never gets an "expose" event; if I try to draw into the OpenGL context without the window being exposed I get the error:

QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined

I have found out that it is rather difficult and not recommended to execute a Windows GUI application from a service on a running desktop session (see How can a Windows service execute a GUI application?).

Now, I don't need the user to see the application, I just need the OpenGL part to work correctly. Is there a way I can "pretend" to expose a window somehow, or is there any other way to get this to run correctly from a system service?

Community
  • 1
  • 1
pholz
  • 684
  • 8
  • 19

1 Answers1

1

Is there a way I can "pretend" to expose a window somehow, or is there any other way to get this to run correctly from a system service?

Two problems you're running into:

  1. If a window is not exposed all pixels rendered to will fail the pixel ownership test and rendering turns into a NoOp for all the pixels. The workaround for that is using wither a PBuffer or (recommended) a framebuffer object. Neither will immediately work with a on screen window, so you'll have to change some code.

  2. In Windows processes started as a service usually don't get access to the graphics hardware, so you're limited to the capabilities of the software GDI OpenGL fallback (limited to OpenGL-1.1, hence no support for FBOs or PBuffers).

If you need GPU acceleration you can either invest into some grid computing GPU hardware (well, actually every GPU could do it, but the drivers disallow it for consumer grade stuff) to get a working OpenGL accelerated context. Or you can migrate to Linux, use a GPU supported by KMS/DRI/DRM and completely circumvent any graphics system. There's no official guide on how to do that, but it's on my (lengthy) ToDo list writing such a tutorial.

If you can live without GPU acceleration, drop a Windows build of Mesa with the softpipe renderer beside your program's .exe; the Windows Mesa softpipe build comes as a opengl32.dll fully API and ABI compatible with the standard opengl32.dll, but is independent of any graphics driver. It gives you OpenGL-3.3 support including FBOs and PBuffers.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • As I understand them none of your options would work for me since the dekstop version of the accelerated GPU rendering is exactly what I want to have in the test: The test should be as good an indication as possible for the correctness and performance of the application as run in a normal Windows desktop environment. – pholz Aug 24 '15 at 09:20
  • I found a different solution: Starting the gitlab-runner binary from the login-user's autostart rather than as a system service (which is the way it installs itself by default) – pholz Aug 24 '15 at 09:46