[Development] The Dynamic OpenGL on Windows Change

[Sean Harmer]

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.harmer at 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