This blog is the first in a series that will show how to use OpenGL with Qt 5. In this article, we shall take a very quick look at Qt’s historical support for OpenGL and then go on to describe the first batch of new features coming in Qt 5.1 that will enhance Qt’s OpenGL support. Upcoming blogs in this series will describe more features and show some simple examples of how easy it is to use Qt for OpenGL development.

A (very) brief history of Qt and OpenGL

Qt has a long history of supporting drawing with OpenGL. Most Qt developers are aware of QGLWidget and maybe the various incarnations of the OpenGL-based paint engines. These allow drawing with raw OpenGL or with the convenience of the QPainter API respectively. In addition to these, Qt also offers some helpful wrappers around other OpenGL object types such as QGLShaderProgram, QGLFramebufferObject, QGLBuffer etc.

During the design of Qt 5, these QGL* classes were marked as “Done” and shiny new QOpenGL* replacements were introduced and placed directly into the QtGui library. The reason for these changes is that the new Qt Quick 2 renderer is based upon OpenGL and so is now a core part of Qt’s graphical offerings. Also, the new QOpenGL* classes can be used as direct replacements for the older QGL* classes. For new code, the QOpenGL* classes from QtGui are recommended.

Qt 5.0 exposed basically the same subset of OpenGL functionality as Qt 4.8 did, which is pretty much the intersection of OpenGL 2 and OpenGL ES 2. This also happens to be the functionality needed by Qt Quick 2. In addition to the Qt 4.8 functionality, Qt 5.0 also makes it very easy to create native windows and OpenGL contexts on any platform. No more messing around with the idiosyncrasies of various platforms to create a context that can support the OpenGL Core profile. Just use QOpenGLContext and save yourself from some grey hairs!

With Qt 5.1, we are beginning the adventure of exposing more and more OpenGL functionality so as to make using OpenGL with Qt simple, elegant and hopefully fun! To this end, KDAB has invested significant resources into pushing the boundaries with Qt and OpenGL.

Functions, functions everywhere!

OpenGL is, to put it bluntly, a bit of a pain to work with on some platforms. One of the major reasons for this pain is the need to resolve entry point addresses dynamically at runtime rather than the build time linker being able to do so. For example, onMicrosoftWindows, the address of any function introduced since OpenGL 1.1 must be resolved at run-time. That is nearly all of functions used in a modern OpenGL application!

To assist with this Qt has provided a couple of helpful utilities: QOpenGLContext::getProcAddress() and QOpenGLFunctions. The former can be used to perform manual resolution of entry points, whilst the latter is a class that has member functions mapping to the common subset of functions in OpenGL 2 and OpenGL ES 2. …read more
Source: FULL ARTICLE at Planet KDE