OpenGL Window

Our reliance on the old QGLWidget has been somewhat of a stumbling block now that the renderer is starting to embrace FBOs and other modern day OpenGL concepts. Fortunately, Qt 5.4 now offers a new way to manage the OpenGL surface in a way that is more compatible with OpenGL 3+ and the Core profile. Furthermore, since Doomsday doesn’t need the OpenGL surface to be an actual QWidget, it will save resources not having to treat it as one.

The current implementation looks like this:

  • Canvas (derived from QGLWidget) represents both the OpenGL surface and the widget that captures incoming input events.
  • CanvasWindow (derived from QMainWindow) represents the top-level window in which a Canvas is housed.

Since there is really no need to couple the input event handling with OpenGL surface management, the input code should be separated into a class called QtInputSource, and the OpenGL surface management should be handled by CanvasWindow, which will be derived from QOpenGLWindow. In other words:

  • QtInputSource just handles input events. It can be installed as a Qt event filter on the main window, so it has visibility to all the incoming events and can react accordingly (i.e., generate suitable Doomsday events and notifications).
  • CanvasWindow, being a QOpenGLWindow, handles all the OpenGL related stuff. It can reformat the native surface when needed without having to delete and recreate any widgets. CanvasWindow can then own a GLFramebuffer instance that represents the default framebuffer object, i.e., the window surface.

All of this is mostly a refactoring, however it then enables rewiring the frame refresh loop to be triggered by the signal that QOpenGLWindow emits when the frame has been swapped.

These changes then allow moving forward with the migration to OpenGL 3.3, and let us remove some inefficiencies in the current swap chain.