[Development] OpenGL Support in Qt5

[gunnar.sletta at nokia.com]

On Jul 16, 2012, at 10:46 AM, ext Sean Harmer wrote:

> 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).

Compatibility between ES and desktop needs to be handled for these classes to be used in Qt. For the core set that Qt/QML currently uses, this is already handled by QOpenGLFunctions. 

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

The problem is mostly the 3.1 profile, as it sits completely outside the hierarchy.

> 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
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development