[Development] OpenGL in Qt 5.1 and onwards

[Sean Harmer]

On Tuesday 15 January 2013 16:37:38 Samuel Rødal wrote:
> On 01/15/2013 02:43 PM, Sean Harmer wrote:
> > Hi,
> > 
> > On Monday 07 January 2013 10:00:47 Sean Harmer wrote:
> >> On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote:
> >>> On Dec 18, 2012, at 2:34 PM, Sean Harmer <sean.harmer at kdab.com> wrote:
> >>>> Hi,
> >>>> 
> >>>> I would like to start a discussion on the future level of support for
> >>>> OpenGL enablers in Qt for those that are interested. So here goes...
> >>>> 
> >>>> I would like to add in a bunch more OpenGL enablers but am not sure on
> >>>> where
> >>> 
> >>>> to best put them. Some things I have in mind are:
> >>> Hi Sean,
> >>> 
> >>> Late reply, but I think all in all this is great.
> >> 
> >> No problem and Happy New Year!
> >> 
> >>> I would like to draw the
> >>> line at 3D scene graph and model loaders and similar as I think this
> >>> falls
> >>> outside the scope of the module, but anything that makes OpenGL easier
> >>> to
> >>> use has my vote.
> >>> 
> >>>> 1) Classes that contain member functions for all OpenGL functions of a
> >>>> given version and profile. E.g. no need to use GLEW or similar. WIP
> >>>> version of this at
> >>>> 
> >>>> https://codereview.qt-project.org/#change,35408
> >>>> 
> >>>> This needs resubmitting against dev of course which I will do after
> >>>> some
> >>>> refactoring of the underlying code-generator and trying an experiment
> >>>> with
> >>>> a different inheritance hierarchy.
> >>>> 
> >>>> Where should this live? It fits in nicely with obtaining pointers to
> >>>> such
> >>>> objects directly from QOpenGLContext. However, it does add size to
> >>>> QtGui
> >>>> so
> >>>> some people may object to this being located there. The vast majority
> >>>> of
> >>>> functions are inline. The other option is to put it into a Qt3D
> >>>> OpenGL-enabler library and create the objects via some factory class.
> >>>> 
> >>>> At present I have a bunch of other WIP patches based upon this work but
> >>>> they could be refactored to resolve the necessary GL functions
> >>>> themselves. Using these classes would make the others easier to
> >>>> implement
> >>>> but not impossible without.
> >>> 
> >>> How much does this add to the library size when they are not used? One
> >>> scenario for QtGui is to "give an OpenGL and an OpenGL context only".
> >>> I'm
> >>> thinking especially about embedded and low-end where library size might
> >>> still matter. Could/should we put these behind an ifdef? Either
> >>> !QT_OPENGL_ES or something else?
> >> 
> >> I'll get some numbers put together and report back shortly but the code
> >> already has a #ifdef QT_OPENGL_ES_2 to remove the desktop
> >> version-specific
> >> and extension classes.
> > 
> > New version of the corresponding patch against dev is at:
> > 
> > https://codereview.qt-project.org/#change,44783
> > 
> > I have the numbers for a size comparison now. For a release build of QtGui
> > from the dev branch on 64-bit Linux I have:
> > 
> > -rwxr-xr-x 1 sean_harmer users 4084848 Jan 14 11:01 libQt5Gui.so.5.0.1
> > 
> > With all of the extension and OpenGL versions classes in this grows to
> > 
> > -rwxr-xr-x 1 sean_harmer users 4781168 Jan 14 15:42 libQt5Gui.so.5.0.1
> > 
> > A delta of 696,320 bytes.
> > 
> > Gunnar/Samuel, I guess it is up to you guys whether to allow this into
> > QtGui or not. There are some knobs we can tweak to reduce the size
> > somewhat though so this is an absolute upper limit:
> > 
> > 1) Don't bother including classes for legacy versions of OpenGL (1.0-2.1).
> > This eliminates approximately one half of the inheritance hierarchy in the
> > classes introduced for OpenGL versions. This should be fine to live with
> > as
> > QOpenGLFunctions already makes most common functions available. Also, new
> > code should really not be using these legacy API's. So really these are
> > just there for completeness. Could leave them in the source but have them
> > compiled out by default via a #ifdef.
> 
> Sounds good to me to not include anything pre-QOpenGLFunctions. Then
> again I'm still not sure it's all worth to have in QtGui. Maybe a
> QtOpenGLEnablers module would be better? If so there might be less harm
> to have the earlier versions too.

Well yes we could put these into an enablers library as part of Qt3D for 
example. Hmm actually it would be better as a new small module so that QtQuick 
can use them. This would mean no access from QOpenGLContext though. I would 
also need to refactor the other patches to resolve needed symbols themselves.

> > 2) Do not include all extension classes. We could identify the most
> > commonly used extensions (somehow) and only include those by default.
> > Again we could allow someone to opt-in to other extensions, either
> > globally or on a case-by- case basis using #ifdefs. Again this should be
> > feasible as many extensions are essentially deprecated by having been
> > merged into the core features of newer versions or have been superseded
> > by new core features.
> 
> Maybe it could just include the extensions that have at some point
> become standardized as part of some OpenGL version? So
> QOpenGLExtension_EXT_framebuffer_blit but not
> QOpenGLExtension_NV_bindless_texture for instance.

The problem with that is that it kind of defeats the point of the extension 
mechanism. QOpenGLExtension_NV_bindless_texture is actually a good one to pick 
on as this is a feature that recent nVidia cards are capable of in hardware 
but which is only available in OpenGL. Direct3D without an extension mechanism 
can not provide access to this useful feature.

The ones I would prefer to exclude are the obsolete ones, not the ones on 
their way into a possible future core feature. Determining which ones go into 
the obsolete set may take a little effort.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at 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