[Development] OpenGL Support in Qt5

Sean Harmer sh at theharmers.co.uk
Mon Jul 16 21:22:24 CEST 2012


On 16/07/2012 19:54, gunnar.sletta at nokia.com wrote:
> On Jul 16, 2012, at 4:54 PM, ext Sean Harmer wrote:
>
>> On Monday 16 July 2012 07:21:23 Thiago Macieira wrote:
>>> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote:
>>>> On Monday 16 July 2012 07:08:38 Thiago Macieira wrote:
>>>>> I'm asking for Qt 5.0: what should we tell Linux distributors to
>>>>> configure
>>>>> qtbase with? Considering what requirements qtwayland has, I think it
>>>>> needs
>>>>> to be -opengl es2.
>>>>>
>>>>> Correct?
>>>> If using wayland then yes I believe so.
>>>>
>>>> If using xcb backend then -opengl desktop works fine.
>>> There's only one build of Qt. The choice is made at compile-time of qtbase,
>>> not at run-time like the platform plugin.
>>>
>>> So everyone should use OpenGL ES 2.
>> Unless they want to support applications that use legacy OpenGL calls or
>> develop new applications that use modern desktop GL.
>>
>> There seems to be a dependency issue here that needs resolving. Qtbase itself
>> has a configure time switch for OpenGL ES vs Desktop whereas the QPA plugins
>> can be decided upon at runtime. Is there some way we can move the GL decision
>> to be runtime too I wonder?
> We've talked about in the past that Qt could internally resolve all OpenGL functions and expose proxy functions which at run time are linked towards the correct library... Incidentally, exactly the problem the patch that started this thread solves, if it gets expanded to include every extension in the Khronos registry.

I almost have this aspect completed now. Should be done in the next day 
or so. Once ready I'll update the patchset.

> The reason we didn't go for this in the past is that end-user applications always link directly against the OpenGL library, so it doesn't matter what libraries Qt resolves at runtime. The app will resolve a different set of libraries and the application will be screwed.
>
> This needs to be solved on the distribution level. It should ship OpenGL ES or OpenGL, or both in the same library if that is what fits.

Yes that would be nice. Hopefully a way forward will present itself soon :)

Cheers,

Sean


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the Development mailing list