[Development] OpenGL in Qt 5.1 and onwards

[Samuel Rødal]

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.

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

--
Samuel