Hi, On Monday 16 July 2012 07:47:10 gunnar.sle...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
