[Development] The Dynamic OpenGL on Windows Change

[Gunnar Sletta]

On 27 Feb 2014, at 22:17, Agocs Laszlo <Laszlo.Agocs at digia.com> wrote:

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

And I agree to all this. It is a good change, and I'm happy to see it.

Also, I would be very surprised if the added if-statements inside Qt makes much of a difference to performance. As long as that logic stays primarily inside Qt, it also doesn't hurt application complexity.

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

This is not how we talked about doing this before. Anything that calls glClear today is already linking against opengl32.dll and should continue to do so. In addition, they are  required to in some way or form tell Qt to use desktop GL which is their preferred choice. For instance, setting the AA_UseDesktopOpenGL application flag to force Qt to use the right OpenGL libraries at runtime. 

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

The point is that none of these applications used ANGLE. They used desktop GL and now they are potentially broken. I think we should set AA_UseDesktopOpenGL to true by default if Qt is configured with "-opengl desktop". (Not saying Qt needs to be built with this option by default though).

The overall goal of this change is that those that Qt takes care of OpenGL for those that do not care or do not know. Those that do care will almost always want proper desktop OpenGL on desktops and should not be hampered by it.

cheers,
Gunnar

> 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development