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.breitme...@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.har...@kdab.com] > Sent: 28. februar 2014 11:41 > To: development@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.ag...@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.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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development