> 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.har...@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.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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development