[Development] The Dynamic OpenGL on Windows Change

andre apoenitz at t-online.de
Thu Feb 27 20:36:51 CET 2014


On Thu, Feb 27, 2014 at 02:28:26PM +0000, Sean Harmer wrote:
> 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).

[And that is a problem by itself.]
 
> 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

Real-world numbers, please.

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

You miss the point that Qt "users" are typically developers themselves,
who have not just their own development machine to take care of (plus
their corporate IT...) but an application they wish to make as widely and
as easily available as possible. Offering a real end user a choice
"Do you wish to install our application on a machine that has good 
OpenGL support, or would you prefer to download an ANGLE based version?"
is a no-go.

Not addressing the problem on the Qt side just shifts the burden to
the "developer-users", multiplying the work needed by a factor in the
order of "developer-users with real end-users".

You could have argued that given the general state of OpenGL support
in the wild it is a questionable choice as "painting abstraction layer",
and some people might have agreed, but consolidating the number of
physical builds helps at least at the user visible layer. ("user" in
the widest sense: Release team, "developer-users", end users)

> This change seems to muddy the waters much more than it helps our end users.

Quite the opposite in my opinion.

Andre'



More information about the Development mailing list