On Thu, Feb 27, 2014 at 02:28:26PM +0000, Sean Harmer wrote: > > 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
As pointed out by Friedmann earlier, the big picture is a somewhat more complicated. This is just the beginning. Besides real OpenGL and Angle there has to be a pure software based option. This is either Mesa llvmpipe, providing OpenGL 2.1, or a D3D11 build of Angle with software rasterizer support. The availability/feasibility of the latter is a bit unclear to me so for the time being the assumption is that it will be Mesa that is added as a third configuration. A dynamic, runtime selection becomes even more invaluable in this case. Instructions like "check if your application is working, if not, copy this opengl32.dll to the executables directory" just don't cut it. The two current builds of Qt is already causing mass confusion and a maintenance and deployment headache. With the rise of Qt Quick Controls OpenGL is not just an option anymore, it is an absolute must at the core of Qt. (which may or may not be ideal but that's another discussion) Having a single build of Qt that works on the widest possible range of target machines is what we should target. Instructions like "download the other build of Qt, in case it happens to be available for your compiler, and try again" just don't cut it. The static, build-time hardcoding of the OpenGL implementation and the windowing system interface is starting to be a problem on other platforms too, given that multiple winsys interfaces and OpenGL variants are becoming gradually available on systems that used to be limited to one well-defined variant. (not to mention the more exotic use cases, see e.g. QTBUG-36829) Once we are comfortable with a dynamically switched solution on Windows, something similar should be rolled out on all platforms, removing the dreaded QT_OPENGL_ES define hell. These ifdefs just don't cut it anymore. > 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 OpenGL 1.1 (i.e. whatever is in GL.h), WGL (the subset in wingdi.h), GLES 2.0 and EGL 1.4. This covers the functions available in opengl32.dll and Angle's libegl+libglesv2. Everything else is queried during runtime using the appropriate getProcAddress variant. Why these exports? Compatibility. Anything that directly calls glClear() today should continue to function. Instructions like "migrate all your code to use a new fancy wrapper class" are not feasible, not in Qt 5.x at least. (not that they are that desirable in Qt 6 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. These applications are broken already today when using the default build of Qt that uses Angle. Which means the developer has to know, already today, that the 3rd party code requires opengl32 and so the application needs to use a matching Qt build. With dynamic GL, there is no issue. The 3rd party library links to opengl32.dll. The application links to QtGui which dynamically loads opengl32. This should work fine. As for statically linking in 3rd party code into the application, that can conflict, yes. This is unavoidable and cannot be skipped with any sort of dynamic OpenGL loading approach, no matter what we do. Best regards, Laszlo _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
