Hi everybody, I would like to raise some concerns around the change that introduced the dynamic selection of OpenGL on windows. For reference the change is at:
https://codereview.qt-project.org/#change,76732 The apparent problem that this is attempting to address is the need for both ANGLE and desktop OpenGL builds of Qt on windows. As you know Qt Quick 2 depends upon having an OpenGL implementation to perform its rendering. On Windows some older hardware and driver combinations do not provide a sufficiently well working OpenGL implementation yet they do have a working DirectX implementation which ANGLE then wraps to provide an OpenGL ES 2 implementation. That’s all fine, some people need ANGLE to be able to use Qt Quick 2 others can use the desktop OpenGL build. So we offer two build configurations of the SDK (multiplied by the other build options e.g. 32 vs 64-bit, MSVC vs mingw etc). What I do not like about this change is that it adds a lot of complexity, leading to more maintenance; it makes the runtime performance worse for desktop and ES2 code paths if using the dynamic GL build option; the user still has to care about ES2 vs desktop OpenGL differences as the dynamic option pulls in the desktop GL header; it exports all of the WGL, EGL and a whole bunch of OpenGL functions from QtGui.dll. Incidentally what was the criteria used to decide which OpenGL functions to export? I see there are a bunch of the old fixed function pipeline functions exported which are of no use in ES 2 and should not really be used in new GL code on the desktop either. Let’s think about that last one. Consider a situation where a customer is writing an application that uses a 3rd party renderer of some sort e.g. VTK, OpenSceneGraph or a map renderer. Their application links to this library which in turn links to opengl32.dll and also to QtGui.dll. Now we have a problem as both opengl32.dll and QtGui.dll both export the GL functions. So in this case the user has no option but to opt for the non-dynamic, desktop OpenGL build of Qt anyway. Exporting the GL symbols from QtGui for the lifetime of the 5.x series seems unwise, especially if the intention is to remove the non-dynamic builds. In summary I do not think this change is worth the costs associated with it. Users that require the ANGLE build should use the ANGLE build. This set should decrease in size as the older hardware/driver combos naturally get refreshed. Users that are doing anything with desktop OpenGL should use a desktop OpenGL build to avoid the above symbol conflicts and the runtime costs. This change seems to muddy the waters much more than it helps our end users. Kind regards, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development