general direction question: OpenGL/Qt Quick

Good morning,
I need some general guidance about working with OpenGL (and Qt Quick). I’d like to avoid heading down roads that lead to dead ends but my vision doesn’t extend very far and my crystal ball is in the shop. (The last time I was fortune telling the client got mad and threw it at me).

I’m interested in combining a 3d graphics library with Qt Quick. The graphics library is written so you can abstract the drawing to your own rendering classes. It already has an OpenGL renderer plugin but it does NOT play well with Qt Quick. So the idea is to rewrite the OpenGL renderer so it will work (with Qt5.1)

I’m an OpenGL noob. Any pointers to OpenGL knowledge would be appreciated. I know c++/c/assembler but not OpenGL.

So far my understanding is:

  • video cards support some subset of OpenGL functionality depending on the manufacturer’s whim.
  • Some of what they support may be buggy/not implemented well.
  • You obtain function pointers at run time which allow you to call desired functions

My questions:

  • Examining Qt5 context classes it appears the functions available are linked to the version requested in the context. Can I mix function calls from different OpenGL versions? If I find that on a specific card a specific function is broken can I replace that single function call with a one from a different OpenGL version?

  • Can I can get pointers to ALL OpenGL functions through the getProcAddress() name resolution?

  • I see there are ARB versions, non ARB versions, EXT versions, and vendor add ons. Can you mix and match function calls or do you have to investigate each one separately?

  • Is there a good place to find information about which cards/versions/functions are broken?

Thanks for your time,


If you request a “compatibility profile” context (QGLFormat::CompatibilityProfile), you can use all functionality in all versions up to and including the requested version. If you request a “core profile” context (QGLFormat::CoreProfile), then deprecated functionality (i.e. the fixed-function pipeline) won’t be available. The distinction is only meaningful in OpenGL 3 and later; in OpenGL versions 1 and 2, each subsequent version added new functionality but never removed any.

I don’t know. The 4.7 documentation says “GL extension function”. If it’s a thin wrapper around the native platform function (e.g. wglGetProcAddress() on MS Windows or glXGetProcAddress() on X11), the Windows function only works for extensions (functions which aren’t in the OpenGL 1.1 API), while the X11 version also works for core functions from any version as well as for extensions.

On Windows, pointers to extension functions may vary between contexts, as they refer to functions within the hardware-specific driver. So on a multi-head system, windows on different displays may have different function pointers for extension functions. If the program can create more than one window, and you can’t guarantee that all windows are on the same display, the pointers returned from getProcAddress() need to be stored as part of the window’s data, not in e.g. global variables or “static” class members.

The version without a suffix will only exist if it’s present in the OpenGL API version provided by the current context as returned by glGetString(GL_VERSION). Extensions should only exist if they are in the list of supported extensions, as returned by glGetString(GL_EXTENSIONS) (or glGetStringi(GL_EXTENSIONS, index) for OpenGL 3 or later).

Usually, the “core” function is either equivalent to the extension or provides a superset of its functionality, but this isn’t always the case. For enumerants, check the GL/gl.h and GL/glext.h headers; if the core version has the same numeric value as the extension, they’re guaranteed to behave identically.

I don’t know of one.

Thank you, that helped a lot. I had completely forgotten about multi head systems too. Do you have a favorite book?

I learnt OpenGL from the second edition of the red book, but that’s rather dated by now. And it doesn’t cover any of the issues discussed here. Most of the rest I learnt from manual pages and the specifications.