On Monday 16 July 2012 05:10:25 Thiago Macieira wrote: > On segunda-feira, 16 de julho de 2012 07.47.10, gunnar.sle...@nokia.com wrote: > > I both like and dislike the idea. Like because it resolves all the > > functions and that way save a lot of pain and dislike because it adds a > > lot of symbols, and I'm a little bit uncertain on the usecase. > > > > Because the functions are not a well defined subclass hierarchy (and nor > > can they be), the user will have to make a compile-time decision about > > which version to code against, making the code less flexible at runtime. > > Will this be a problem? > > Let me ask this. How will Qt 5 work under this scenario: > > - QtGui compiled on a regular Linux box, such as current Fedora, Ubuntu, > openSUSE, etc. > - Wayland plugin > > The best Wayland plugin's GL integration is "wayland_egl", which requires: > contains(QT_CONFIG, opengles2) > > Do we conclude that Qt 5 should use EGL & OpenGL ES 2 for everything, > recommend it for everyone, even on desktop systems?
IMHO, no. If Desktop GL capabilities are present on the system then Qt should enable their use. In time Wayland maybe adopted by Desktop OpenGL vendors without the need of pulling in X and GLX but for now it is ES2 only. In the case of OpenGL ES2 (including Wayland) the proposed classes would simply not be compiled and there would be no deficit compared to what already exists. If desktop GL is selected at configure time then we can enable additional features in the OpenGL stack of Qt e.g. geometry and tessellation shader stages; instanced geometry; vertex array objects; uniform buffers;... Having such facilities available makes many more things possible or the same things more performant than ES2. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer 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
