[Development] OpenGL Support in Qt5

[lars.knoll at nokia.com]

On 7/23/12 10:55 AM, "ext Samuel Rødal" <samuel.rodal at nokia.com> wrote:

>On 07/16/2012 10:59 PM, ext Fredrik Höglund wrote:
>> On Monday 16 July 2012, Thiago Macieira wrote:
>>> On segunda-feira, 16 de julho de 2012 07.47.10,
>>>gunnar.sletta at 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?
>> 
>> The platform interface API and the rendering API's are orthogonal.
>> 
>> It is possible to use the full OpenGL API with EGL, and to use OpenGL
>>ES 2
>> with GLX. The OpenGL implementation might not support all API's however.
>> 
>> For example the NVIDIA driver supports OpenGL and OpenGL ES 2 with GLX,
>> but doesn't support EGL. The Tegra driver supports EGL and OpenGL ES 2,
>> but doesn't support the full OpenGL API.
>> 
>> At any rate, it certainly is possible to use the full OpenGL API with
>> wayland, and the wayland gears demo does that.
>
>Yep, it's not really an issue of OpenGL ES 1.x vs OpenGL 2.0 vs OpenGL,
>but an issue of whether to use GLX or EGL.
>
>We could build two versions of the xcb plugin, one that uses GLX and one
>that uses EGL, but it might be nicer to have just one version that uses
>both, when available, and chooses an appropriate version based on
>QSurfaceFormat::RenderableType and available EGL / GLX extensions.
>
>The tricky part might be what to do about the qopengl.h header, which
>includes GL/gl.h or GLES2/gl2.h (or its equivalent on mac) depending on
>how Qt was configured. Applications that currently do "QT += opengl"
>also assume that they will automatically get linked against the proper
>OpenGL library. Maybe we could make a proxy OpenGL header and library
>that forwarded to the correct implementation based on the current
>QOpenGLContext's QSurfaceFormat. Such calls, like glClear() and
>glDrawArrays(), would incur an extra cost though.

A solution, where we have our own GL header file and dynamically map it to
the right implementation sounds tempting. In that case app developers
wouldn't need to care and would just use the GL headers shipped with Qt.
This could also give us the option to dynamically switch between the
built-in GL library and ANGLE on Windows.

Since it would be a pure forwarding call, I don't think that cost would
matter a lot.

>And it's not just applications, Qt also uses OpenGL symbols directly in
>the paint engine, even though its present in both the OpenGL ES 2 and
>OpenGL libraries.

If they also use our own gl header files this shouldn't be a problem,
right?

The place where I can possibly see some issues is with 3rd party libraries
that unconditionally link against one of the GL libraries. If an app uses
these we need to make sure Qt also uses the same GL implementation.


Cheers,
Lars