On Jul 16, 2012, at 10:46 AM, ext Sean Harmer wrote: > 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).
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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
