[Development] OpenGL Support in Qt5

[gunnar.sletta at nokia.com]

I both like and dislike the idea. Like because it resolves all the functions and that way save a lot of pain and dislike because it adds a lot of symbols, and I'm a little bit uncertain on the usecase. 

Because the functions are not a well defined subclass hierarchy (and nor can they be), the user will have to make a compile-time decision about which version to code against, making the code less flexible at runtime. Will this be a problem? 

On Jul 13, 2012, at 4:00 PM, ext Sean Harmer wrote:

> Hi,
> 
> I have pushed the following WIP patch for review:
> 
> https://codereview.qt-project.org/#change,30554
> 
> The idea of this is to provide a set of classes that expose the OpenGL 
> functions specific to the version and profile of the corresponding 
> QOpenGLContext.
> 
> This means that it is no longer necessary to use GLEW or similar or to 
> manually resolve OpenGL entry points by hand. This allows developers using 
> these classes to get per-context entry points easily and to also get compiler 
> errors rather than runtime errors if they try to use a function not supported 
> by that {version, profile} of OpenGL.
> 
> The set of QOpenGLFunctions_<Major>_<Minor>_<Profile> classes are generated 
> directly from the official OpenGL spec files as published by the Khronos 
> group. As such we could potentially make the generation of these classes part 
> of the qtbase bootstrap process. This would require importing the OpenGL spec 
> files into the qtbase repo along with the code generator.
> 
> The current WIP patch exposes the version specific functions via 
> QOpenGLContext::versionFunctions() at present as there already exists a 
> function QOpenGLContext::functions() which returns a pointer to a 
> QOpenGLFunctions object.
> 
> QOpenGLFunctions provides basically the same as the new classes but for the 
> common subset of Desktop OpenGL 2 and OpenGL ES 2 as this is what is required 
> by Qt itself (e.g. in QQ2).

QOpenGLFunctions also has shortcuts for functions it knows at compile. It uses an ifdef Q_OPENGL_ES_2 to directly call the actual function, without the GetProcAddress in the between, making it slightly faster for embedded. 

> 
> Another motivation for these new classes is that the existing QOpenGLFunctions 
> is not enough to support modern OpenGL on the desktop. It cannot answer 
> questions such as "are geometry shaders supported?". Geometry shaders are 
> available in Qt4's QGLShaderProgram but are disabled in Qt 5's 
> QOpenGLShaderProgram at present.

IIRC, this is because the extension we are using is not the one that ended up in the later core profiles, so we disabled them to potentially use the "right ones" later on.

> If we combine these proposed classes with the extension resolved (which should 
> be improved and made public) then we would able to easily check for support 
> (either as a core feature or via an extension) and also be able to easily get 
> access to resolved function entry points in the implementation.



> It would be a fairly simple job to extend the code generator to create classes 
> for OpenGL extensions too (they are also in the spec files). I am currently 
> thinking that the extension matcher can be used to query the available 
> extensions and then as a factory to a family of classes that each represent 
> one extension.

It is a bit "odd" right now, that the 3.1 functions do not inherit the 3.0 functions, but rather redefine the whole funciton set. I get that you did this because of that the removed functions are only part of the ARB_compatibility extension, which you are explicitly not dealing with.

> 
> I would like to seek opinion on whether people are happy with this general 
> approach and how it should be placed in relation to the existing 
> QOpenGLFunctions::functions(). Alongside it? Replace it?

The QOpenGLFunctions class provides a bridge between OpenGL ES 2.0 and OpenGL 1.x (with common extensions) and OpenGL 2+, making sure we can easily switch between the two based on the same codebase. This patch goes in a different direction, tying the codebase to a specific version.

It solves a very different usecase than the existing functions class, so I would prefer along side it, rather than replace it.

> I do worry about the number of added symbols to QtGui though - OpenGL is not a 
> small API. Perhaps adding these classes as plugins would be a good idea?

I'm also bit worried about the amount of symbols we're adding to the library with this. When configure detects ES, we could at least make then ifdef'ed out, as they will not be used anyway...  I also briefly considered a static library next to QtGui, but I do not think we want another libQtOpenGL library in addition to the one we already have :)

> 
> I believe that such a framework coupled with QWindow would make Qt5 an 
> excellent platform for OpenGL development as it would allow us to develop 
> additional OpenGL enabler classes easily e.g. QOpenGLVertexArrayObject.

Will it really? Because of the lack of subclassing between the classes, the 3.1 profile will have to be special cased as a separate branch now.


> Comments/thoughts/flames?

If we do this, then I would also like us to provide the ES functions as well.


cheers,
Gunnar