[Development] OpenGL Support in Qt5

[Samuel Rødal]

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.

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.

--
Samuel