[Development] The Dynamic OpenGL on Windows Change

Fri Feb 28 13:16:01 CET 2014

Since i haven't followed the discussion in detail, based on which assumptions 
do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds
like a very bad idea. Relying on QOpenGLFunctions makes more sense.

But right now i don't really see how this buys anybody anything, you usually 
need to know which renderer to use, usually there is a switch in software if 
they have different rederers so the user can change them if they don't work
as expected. I have never really seen any runtime detection that works really
well.

Best regards
Björn Breitmeyer

-- 
Björn Breitmeyer | bjoern.breitmeyer at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions 
Am Freitag, 28. Februar 2014, 11:49:56 schrieb Agocs Laszlo:
> You cannot include multiple GL headers. In a dynamic build you have the
> desktop GL header ( + qopenglext.h), just like in a 'desktop' build. This
> does not change at all.

> Runtime errors are not a problem since all ES-specific paths are guarded by
> the appropriate condition.

> I realize however that there are genuine concerns around exporting all the
> symbols from QtGui, and that the approach will most likely not scale to
> other platforms. A compromise could be to revert the change for 5.3 (since
> it is anyway behind an experimental configuration option) and instead try
> gradually introducing an alternative approach in future releases:

> 1. Leave code that directly calls OpenGL functions alone. Instead, extend
> QOpenGLFunctions with the common subset of OpenGL 1.x and ES2 functions
> which are missing today. This would allow writing
> context->functions()->glClear() etc. which is not possible today.

> 2. Once this is in place, all of qtbase and qtdeclarative (and later all
> other modules) have to be changed to stop directly calling OpenGL
> functions. Instead, they must rely on QOpenGLFunctions (which they most
> likely do already for GL 2 specific calls anyhow). 

> 3. QOpenGLFunctions gets platform specific backends that perform dynamic
> loading of the OpenGL implementation. For example, the Windows backend
> would do the tests for choosing between desktop - Angle and then
> dynamically load the selected implementation. QtGui stops linking to
> opengl32/libegl/libglesv2.

> 4. The windowing system interfacing code, for example all the usage of WGL
> and EGL in the windows platform plugin, has to be placed behind a new
> private wrapper similar to QOpenGLFunctions. This could expose an EGL-style
> API, with platform specific backends  that provide an implementation using
> the dynamically resolved EGL/WGL/GLX functions.

> Another alternative would be to continue betting on Angle as the primary
> OpenGL enabler on Windows, and investigate how well the software rasterizer
> fallback in D3D11-based Angle works. As I understand this would be
> available on Win7+ in VS2012+ builds. If this could solve the issues we see
> today with virtual machines and machines without decent drivers, it might
> reduce the urgency for needing a true dynamic GL solution. 

> Cheers,
> Laszlo
> 
> -----Original Message-----
> From: Sean Harmer [mailto:sean.harmer at kdab.com] 
> Sent: 28. februar 2014 11:41
> To: development at qt-project.org
> Cc: Gunnar Sletta; Agocs Laszlo
> Subject: Re: Re: [Development] The Dynamic OpenGL on Windows Change
> 
> Hi Gunnar,
> 
> On Friday 28 February 2014 07:14:24 Gunnar Sletta wrote:
> 
> > 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.
> 
> 
> What I don't understand, and which is quite likely entirely my fault as I'm
> 
 rather sleep-deprived recently (new baby), is that to me it seems like
> situations such as trying to use desktop GL with an ES 2 build or vice
> versa would have until now resulted in compile time errors. Now they will
> become potential runtime errors (e.g. GL_INVALID_ENUM). Also, is it safe in
> #include the ES2 headers on top of the desktop ones now and in the future?
> That's a genuine question, I honestly don't know.
> 
> If everybody else is happy to live with this then I'll shut up. We should 
> still consider if it makes sense for QtGui to export these symbols or
> whether 
 they should be moved to a new library though.
> 
> Cheers,
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4854 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140228/465ab0b8/attachment.bin>