Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Porting GLEW-based OpenGL code to Qt 5
tommy last edited by
I have large libraries of OpenGL code that works under Qt 4.8 using GLEW as the OpenGL function resolver. Qt 5.3 breaks it by forcing the use of Qt's native OpenGL API, which explicitly excludes GLEW. I want to port this code to 5.3 with the absolute minimum of source changes.
As I understand it, in Qt 5 we are supposed to put all our OGL code in methods of classes derived from QOpenGLFunctions_x_x_x, whose member functions expose the OpenGL API for a given version and profile. On the other hand, GLEW is a pure compile-time resolver that does not impose any class structure on the code that uses it.
It is true that much of my OGL code is in classes derived from QGLWidget, which provides the required OGL context. So would it be sufficient to make those classes children of QOpenGLFunctions_x_x_x as well? However I have also a good deal of "classless" code that works (I guess) because the OpenGL driver holds a "current context". Repackaging that as class methods would require a lot of rewriting, both of that code and things that call it. Can that somehow be avoided in the "New Qt"?
And how would you do it if you needed to select the OGL version dynamically?
Please answer only if you have actually done it.
ZapB last edited by
For the class based functions you can either inherit from QOpenGLFunctions_blah or you can instantiate an instance of that class and store a pointer to it as a member variable. Then do a simple search/replace of gl* with m_funcs->gl*.
For the free functions I would suggest passing in the functions object pointer and doing a similar search and replace.
Reminds me that I need to see what changes are needed to Qt to allow GLEW to work once again. may be tricky with the dynamic OpenGL implementation selection stuff now landing.
tommy last edited by
Having now ported and rebuilt one program using the affected libraries, I can say it was not too bad. Especially considering that numerous source changes unrelated to OpenGL were also needed to get from 4.8 to 5.3.
If Qt 5's native support of OpenGL is as good as advertised, then I won't miss GLEW much, because my "free" code really should be moved into the using classes. It would be nice if Qt could somehow provide global access to the OGL API without explicit function pointer dereferencing, as GLEW does. But I assume it is still possible to package "free" functions in such a way that GLEW could be used without those header conflicts. The main problem is who calls GlewInit().