OpenGL in Qt 5.1 - Part 1

Vendor specific extensions are also provided for. For example QOpenGLExtension_NV_bindless_texture. However, there is only a class for an extension if that extension exposes new API.

There is another way to use the QOpenGLFunctions_<MAJOR>_<MINOR>_<PROFILE> classes that I did not mention here which is to subclass from the relevant class:

For example:

class MyGLStuff : protected QOpenGLFunctions_4_3_Core
{
public:
    MyGLStuff()
    {
        initializeOpenGLFunctions(); // Assumes current context

        glVertexAttribDivisor(...);
    }
};

Hope that helps.

In fact Qt 5.0.2 should start providing pre-compiled binaries against desktop OpenGL. Initially this will be 32-bit against MSVC2010 but the number of package configurations provided will hopefully increase with future releases. If you wish to help with release testing such packages they can be downloaded from [http://releases.qt-project.org/digia/5.0.2/latest_successful/](http://releases.qt-project.org/digia/5.0.2/latest_successful/)

I appreciate that the class interface for GL functions means well, but it is a potential disaster in the making:

"Disaster" seems a little strong.

1) GL extensions come out much more often (in particular vendor extension) that Qt versions

Qt has moved to time-based releases with a period of approximately 6 months. So although there may be some lag between new extensions being released and a Qt helper for it becoming available it is not going to be very long.

2) a number of OpenGL and OpenGL ES2 extensions have the same name, but are radically different [the biggest one being GL_EXT_separate_shader_objects, for GL that is a based off of fixed function pipeline and for GLES2 it is for programmable function pipeline and looks more like GL_ARB_separate_shader_objects].

The classes are simply enablers. Nobody should expect the existence of such classes to be a substitute for knowing what they are doing. If using such extensions then code would likely be protected by #if defined(QT_OPENGL_ES_2) or even in compilation units that are conditionally compiled based upon the build target. For the particular extension you mentioned, the only thing they have in common is the name. The entry points, and hence member functions are different, so trying to use the ES2 extension in code compiled for desktop GL will result in a compilation error.

3) attempting to wrap GL functions in macros to make tracing GL errors is utterly hosed now in Qt.

No it isn't. You can still easily wrap GL function calls in macros if you wish. However, these days it is preferable to use KHR_debug or similar (if available).

One of the justifications for this system is that the GL extension helper headers conflict with Qt headers should make everyone worry: this means that Qt does naughty things in the global namespace. Old crankly GL developers that have had to deal with Qt already know this on embedded: including EGL headers under a large variety of conditions in an X11 environment yields all sorts of bizarre compile errors.

One of the original motivations was indeed the difficulties imposed by the Qt headers in Qt 4 times. The OpenGL related headers in Qt have undergone large cleanups in Qt5 so the situation is now much better. I have had no trouble using Qt and OpenGL 3, 4 or ES 2 out of the box on Windows, OS X, Linux, QNX, Blackberry, and embedded Linux on various platforms (e.g. imx53). Others have reported success with the rasp-pi and other platforms. If you know of problematic platforms then please report them.

This seems like utter over-engineered non-sense too. Come on people, a whole set of freaking classes just to fetch function pointers? SDL, had one simple function to do this [to handle the hassle where core functions are not returned by the function pointer fetcher function of WGL and EGL]. Worse, the files implementing this stuff is likely machine generate [which is fine], but the machine generate file is in the repos, the header file alone is 903K . Brilliant, an almost 1MB header file for this. In contrast, GL/glext.h, the file that defines all the extensions is at 234K.. oodles smaller and much more trivial for a compiler since all it defines is functions (and macros).

Based on your comment about header file size I assume you are referring to the extensions. So one class per extension is over-engineered? I can't recall the details of how SDL handles this but one advantage of using class instances to contain the function pointers rather than polluting the global namespace is that it is much easier to handle the case of multiple contexts resulting in different addresses for the same function (e.g. multiple GPUs or even the same GPU on MS Windows).

Yes the machine-generated header is in the repository, but as noted it is in an optional static library. So people will only pull it in if actually requested explicitly. Even then, it is not as bad as you make out. Some of the file is for desktop OpenGL, the remainder for ES 2 so only the section relevant to the target build get included. Furthermore, much of the file is inline functions which the compiler will only generate code for in the final executable if the function is actually called. So the compiler can happily skip the vast majority of this file.

As with all of the things here, they are optional. If you personally do not want to use them, then don't. End of story. For others that cannot be bothered with the hassles of resolving entry points then these classes will help. If people later decide something in them is too heavy they can be replaced with hand-rolled code at a later date.

This is begging for all sorts of un-fun since there are member functions with the same exact names as the GL functions. Brilliant. I shudder at the syntax of passing these function addresses around (since member functions pointer syntax is terribly ugly). Going further, some the the Qt wrapped GL functions do different things than the GL functions [glBindFramebuffer for instance]. This is done in the name of being useful, but will quite likely make all sort of problems later down the line.

The naming is a simple one-to-one mapping from OpenGL function to member function so as to not introduce any surprises. Why do you wish to pass the member function pointers around at all? These are objects, pass a pointer to the object then call the member function or depending upon the structure of your code it might be easier just to create a second instance (for an extension class) or fetch cached instance from the QOpenGLContext (for core functions class). The only callback functions that I can think of off-hand in OpenGL are the ones relating to the various debug extensions. Even with those the callback is a user-defined static non-member function.

Your statement about the glBindFramebuffer wrapper is incorrect. These classes do not introduce any custom behaviour, they are simply thin wrappers that resolve entry points. If you are referring to the QOpenGLFramebuffer::bind() function, then yes it does add additional behaviour but that is clearly documented.

Your statement about the glBindFramebuffer wrapper is incorrect. These classes do not introduce any custom behaviour, they are simply thin wrappers that resolve entry points. If you are referring to the QOpenGLFramebuffer::bind() function, then yes it does add additional behaviour but that is clearly documented.

Get it correct. My statement about glBindFramebuffer is correct. It substitutes 0 with the default framebuffer. That is NOT the same behavior as GL vanialla glBindFramebuffer. Now enter C++ code, someone write glBindFramebuffer(0) within a class or outside a class and it does DIFFERENT things because it is a different function getting called.

No it isn’t. You can still easily wrap GL function calls in macros if you wish. However, these days it is preferable to use KHR_debug or similar (if available).

You are kidding right? One of the most important bits for debugging is a file and line number that originated the bad GL call. The only way to insert that data is via macros. KHR_debug provides a means of creating labels, but to get line and file one needs macros. But ok, you can still do the macro thing right? That is a big freaking depends. Suppose the macro system is something as simple as:

GL_call(function_name, arguments)

template_GL_call(function_name, arguments, FILE, LINE);

where template_GL_call is a template function using the function pointer type and arguments to do the right thing. This will not work with the Qt system because in the Qt system you need to pass a this pointer to make the above work. OH. But ok, then one can then do a redefine like this, via machine generate jazz:

#define glFoo(a,b,...) debug_glFoo(a,b,c,..., LINE, FILE)

where debug_glFoo is implemented in a C/C++ machine generate file. This does not work either because Qt headers will have the same exact function names as the GL as class member functions.

This entire hassle could have been avoided if the Qt class member functions where different, for example dropping the gl prefix, or using a slightly different prefix, say for example qtgl. You could make the argument that one could define one's gl calling functions with one's own prefix, so a developer code would one do

my_glFoo

which expands as according to a macro. But this is wrong. Qt made the addition, not the developer. Moreover, in light of glBindFramebuffer doing different things, then it is really important to know precisely which one is called. Again the simplest solution would have been for the qt class member functions to use a different prefix than gl.

There are a number of situations where one does pass function poonters around (typically to do very similar things that have similar usage patterns, for example querying attributes and uniforms of a GLSL program). Now one needs to pass the this pointer around and use that particularly hideous pointer to member function syntax. Admittedly it does not happen often, but it does happen and is useful.

Get it correct. My statement about glBindFramebuffer is correct. It substitutes 0 with the default framebuffer. That is NOT the same behavior as GL vanialla glBindFramebuffer. Now enter C++ code, someone write glBindFramebuffer(0) within a class or outside a class and it does DIFFERENT things because it is a different function getting called.

That would be true only if we redefine the function in the global namespace which we are not doing, these are member functions of a class. OK if you subclass then you should care for what function you are calling. However, the QOpenGLFunctions_4_3_Core class and friends do not introduce any custom behaviour at all. These are not the subject of this blog though.

The code you are thinking of is in QOpenGLFunctions which is the historical set for the 2.x/ES2 common subset or maybe in QOpenGLFramebufferObject::bind(). Also as I pointed out earlier where Qt does introduce custom behaviour it is documented that is does so.

You are kidding right? One of the most important bits for debugging is a file and line number that originated the bad GL call. The only way to insert that data is via macros. KHR_debug provides a means of creating labels, but to get line and file one needs macros.

No I am not kidding at all. First of all let's take KHR_debug, this can be executed such that the message callback is called synchronously. Therefore in your callback you can print out the precise call stack that led to the error which is even more information than file name and line number.

Also, macro-based debugging still works perfectly fine. For example assume we have a class that inherits from QOpenGLFunctions_4_3_Core (the simple wrapper class with no additional logic):

#define _DEBUG
#ifdef _DEBUG
static void checkOpenGLError( const char* stmt, const char* function, const char* file, int line )
{
    GLenum err = glGetError();
    if (err != GL_NO_ERROR)
    {
        qDebug() << "OpenGL error" << hex << err << dec << "at" << stmt
                 << "called from" << function << "in file" << file << "line" << line;
        abort();
    }
}

    #define GL_CHECK(stmt) do { \
            stmt; \
            checkOpenGLError(#stmt, Q_FUNC_INFO, __FILE__, __LINE__); \
        } while (0)
#else
    #define GL_CHECK(stmt) stmt
#endif

Then in code call as:

void BasicUsageScene::render()
{
    // Introduce a GL_INVALID_VALUE error
    GL_CHECK( glClear( /*GL_COLOR_BUFFER_BIT*/ GL_TEXTURE_2D ) );
    GL_CHECK( m_vao.bind() );
    GL_CHECK( m_shaderProgram.bind() );
    GL_CHECK( glDrawArrays( GL_TRIANGLES, 0, 3 ) );
}

this then aborts with output of "OpenGL error 501 at glClear( GL_TEXTURE_2D ) called from virtual void BasicUsageScene::render() in file ../ex_debug_macro/basicusagescene.cpp line 66"

As for passing around function pointers and a pointer to the object, well there are solutions for that sort of thing. I agree that the C/C++ syntax for function pointers is horrible though.

Once again, if you don't find this sort of thing helpful then fine just don't use it. Meanwhile, others have found it useful. At the end of the day, it's another design choice.

Ok, let me get this straight, you think it is a good idea to have a developer explicitely do:

SOME_MACRO()

wrapped around each GL call? This is not only ugly, it is not going to work for GL functions that return a value. Rather than harping on how bad what Qt has is, I will point in a direction that would be better:

0) Do not use the prefix gl for these member functions. Use a different prefix, so that at a glance one can know it is a member function or not.

1) Go a step further. Rather than use member functions, just make the pointers to functions public declared with the const modifier. That way no one will accidentally change their values. Have the implementation of assigning their values do the ugly thing of the const_cast. By having simple function pointers, one can use these symbols exactly as one would anywhere else.

2) Go even further. One of the points of these classes is that sometimes the function pointers returned are different subject to what GL context. Rather than have an end developer must keep track of what GL context was curernt when those objects loaded their function pointer, make the QGLContext objects themselves have the objects that store the function pointers. This automatically has that the correct function will be used from the currect GL context. Win-Win.

3) Even further, one can then add a member function, for each GL function, that has a pre-code and post-code that a user can override. Such pre-code can be for example calling the GL function directly to create a label for KHR_debug, writing to a log file, whatever. One can have that under the pre and post code are made active only under debug for example, or possible decided by properties of the QGLContext before it creates the underlying GL context. Implementation would be handled by member function pointers to avoid extraneuos if's in the execution.

The above is admittedly harder to implement and requires more for-thought that the current system, but it would be so much more useful for debugging, logging, etc.

Ok, let me get this straight, you think it is a good idea to have a developer explicitely do:

SOME_MACRO()

wrapped around each GL call? This is not only ugly, it is not going to work for GL functions that return a value.

I didn't say it was pretty, macros often aren't, but yes it does work for functions that return a value, just call GL_CHECK( val = glIsEnabled(blah) ) for example.

Thank you for your other suggestions, we'll take a good look at them. Please note that for the function objects for the core functionality the QOpenGLContext already caches the object per-context as you suggest in item 2). We can look at enabling this for the extension functions too.

For 1), the shared back-end classes used in the implementation contain the raw function pointers, perhaps these could be exposed.

One thing worth mentioning that QGLOpenGLContext does get right, it does do 2), i.e. the function pointer object is fetchable for the context, but the extension function stuff does not follow this.

Yes this was due to the extensions being split out into their own static lib. Would still be possible of course, just requires some extra casting.

Yes, I would love to see OpenCL support added too. I don't know if anybody is looking into this or not. Yes, I will add cross-links to the other articles once they are published.

Hi, the class in the QtOpenGL module are deprecated and have a QWidget dependency. Of course if you want to you can still use QGLWidget but the other classes all have more up to date equivalents in QtGui which can all be used as drop-in replacements. For example, you can create a QGLWidget and then instead of using QGLShaderProgram, use QOpenGLShaderProgram.

The reason this works is that internally QGLWidget creates a QGLContext, and that is in turn implemented in terms of a QOpenGLContext from QtGui.

The QOpenGL* classes in QtGui will continue seeing further development and improvement, whereas the ones in the QtOpenGL module will not. Hope that helps to explain it.

stereomatching,

You need to enable to compatibility profile to do the most simple drawing in OpenGL. They (OpenGL, not Qt) really, really don't want you doing anything at all outside of shaders. To enable, put this in your QGLWidget constructor:

QGLFormat qglFormat; qglFormat.setVersion(3, 2);//Or whatever your version is here. qglFormat.setProfile(QGLFormat::CompatibilityProfile);

setFormat(qglFormat);

Try using the template version of the function like this:

m_funcs = m_context->versionFunctions<QOpenGLFunctions_4_3_Core>();

If QOpenGLContext is properly done you should be able in integrate Ogre like you would in GLFW, SFML, SDL, .... or anyother windowing toolkit.

I haven't tested it yet. But hopefully there isn't a ton of abstraction there that will mess things up. If not it should be cake to integrate Ogre.

Hi, yes I plan to do a blog series showing how to do just this. I'll try to get this done soon.

Thanks in advance. Your blog is quite interesting.

Hi, what's the problem with using an OpenGL Core profile with Qt? Which version of Qt are you using? Is this with QWindow or with QtQuick 2? Which platform?

Ah, indeed QPainter and OpenGL Core profile do not play nicely together yet. For info I am currently fixing the Qt Quick 2 renderer to work with a Core profile context. This should make it into Qt 5.2.0. I have it working locally and am just tidying up the patch and testing on all platforms that I have access to.

Please file a bug at bugreports.qt-project.org about these.

The latter. The former is for use on the desktop when you have OpenGL 4.3 support available.

Hopefully when nVidia release the Tegra 5 we'll also be able to use OpenGL 4.3 on that embedded target too.

You can still use QGLWidget. Internally it uses QOpenGLContext anyway. There will be a QOpenGLWidget coming in Qt 5.4.

QSurfaceFormat now has setSwapInterval(int) which you can call with a zero argument to disable vsync (or -1 for adaptive vsync).

thank you, sean

Sorry but I have no experience of that particular chipset. However, QtQuick2 uses only OpenGL ES 2 features but it does require at least OpenGL ES 2 (or OpenGL 2.x) as it makes extensive use of shaders.

Have you tried profiling to see where it gets very slow? Take a look at both the CPU side and also GPU side with a tool like apitrace.

Good luck!

Picking and selection are undergoing development right now. We know exactly what form it will take yet. At present we are focussing on ray casting.

Thanks for your reply. Dont you think that raycasting algorithm is slow for huge rendering system (3-5 million points)? I need to calculate intersections and check the all nearest points. If I store all coordinates in one QVector or QHash, It takes time to check nearest points.

Thanks for your helping. Regards, Zsolt

It depends :) Usually one would use some kind of spatial structure to eliminate non intersecting sub trees. Then proceed to a narrow phase where if needed you can test against individual triangles.