[Development] OpenGL Support in Qt5

[Samuel Rødal]

On 07/23/2012 12:25 PM, Knoll Lars (Nokia-MP/Oslo) wrote:
> 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.

Yep, unless we're on a system (desktop typically) where we'd want to use
either libGL.so or libGLESv2.so depending on the
QOpenGLContext::currentContext()->format().renderableType(). We could
store this information in TLS on makeCurrent() though, so it would look
something like this:

void glClear() {
if (tls->usingGLESv2)
   glesv2funcs->glClear();
else
   openglfuncs->glClear();
}

Mesa's libGL.so and libGLESv2.so both link against libglapi.so if mesa
is configured with --enable-shared-glapi, but that might not always be
the case.

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

--
Samuel