[Development] OpenGL in Qt 5.1 and onwards

[Samuel Rødal]

On 01/15/2013 05:05 PM, Sean Harmer wrote:
> 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.

I guess I see the value in Qt providing them, it just seems a bit 
strange to include vendor-specific extensions. For OpenGL ES for 
instance there are at least NV, QCOM, ARM, AMD, IMG, and other vendor 
prefixed extensions. I see now that you've included most of those 
already, apart from the ARM ones? 3DFX extensions might be a bit 
obsolete these days though, who's going to write new code using those? :)

Maybe a separate header for each vendor would make sense to not have 
such a huge header file.

--
Samuel