[Development] The Dynamic OpenGL on Windows Change

[Robert Knight]

> 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

Do you have any idea of numbers or how old "old" is? What about Chrome
/ Mozilla's experiences
with WebGL for example? I believe Chrome did or were using ANGLE for
WebGL on Windows?

On 27 February 2014 14:28, Sean Harmer <sean.harmer at kdab.com> 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).
>
> 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
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development