[Development] OpenGL Support in Qt5

[Sean Harmer]

Hi,

On Monday 16 July 2012 07:47:10 gunnar.sletta at nokia.com wrote:
> 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.

The use case is for anybody writing an OpenGL application with Qt. As you say 
it removes one of the largest  pain points by allowing developers to 
immediately get hold of resolved entry points. Usually this means doing it 
manually or using GLEW or the like. However, even with GLEW, managing the 
entry points across contexts and threads can be some work.

As the entry points are provided in classes rather than the global namespace 
it also offers the safety of compilation errors if someone tries to use a 
function not in that version rather than runtime errors.

Another use case will be within Qt itself. When coupled with an easy way to 
resolve extension entry points it will allow QOpenGLShaderProgram etc to 
discover if a certain feature should be enabled (e.g. geometry shaders, 
tessellation shaders, vertex buffer objects).

As for the symbol count, I agree that this is an issue. I am open to 
suggestions on how to handle this. We could make it an optional feature 
enabled at configure time; somehow look at factoring it out into a new 
QtOpenGL library (not the existing widget based one) so that it is only linked 
in if people really want it. Although in those cases Qt itself would not be 
able to use it.

> 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?

Why are they not a well-defined class hierarchy? The only assumption I have 
made in the suggested hierarchy is that a Core profile context is forwards 
compatible and a Compatibility profile context is not forwards compatible 
(i.e. still has deprecated functions present). With this small simplifying 
assumption the class hierarchy seems to be well-defined - unless you have 
spotted something I have missed of course?

I think the decision can be deferred to runtime with the usual kind of 
fallback mechanisms. I.e. 

* Request the highest version context your app supports
* If successful, obtain functions object for that version.
* Otherwise decrement version and try to obtain new context and disable 
features that rely on higher version being available (if no extension also 
supports that feature).
* Rinse and repeat down to minimum version your app supports

Cheers,

Sean