[Interest] QML and OpenGL conflicts

[Marc Gilleron]

In case we want to share our context with QtQuick, which one should we pick?
Is there a main context Qt uses for its views (not only QtQuick because
classic widgets use OpenGL too I guess)? Or do we have to share QtQuickView
contextes as they are created?


2015-06-05 20:31 GMT+02:00 Marc Gilleron <marc.gilleron at gmail.com>:

> Here is where we currently are:
> - Threading our OpenGL code would currently mean having a thread between
> our project and Qt-related code.
> - Wrapping OpenGL code in makeCurrent() is not done and is not planned by
> the team due to optimizations and refactoring that never has been
> necessary. I agree it might sound not very clever, but that's the way it is
> now.
> - Share the context with Qt Quick might be an option, to be tested because
> there is a chance it doesn't works as you said. However we still think
> about threading so that both renderers don't slow each other. We recently
> had a test case where the two renderers worked, however performance dropped
> dramatically, not sure why.
> - Note: it's not all about render(), but also ressources loading that may
> happen at almost anytime within the main thread.
>
> Another tricky point for the approach is the complexity of our project and
> the way we had to integrate Qt in it.
> At the moment, the GUI/QML interacts directly with the main thread, where
> our renderer is also doing its operations at different places (far away).
> So, maybe we'll have to separate those threads... but if we do, I wonder
> at which level, and how windowing will work since our renderer has its own
> window.
>
>
> 2015-06-05 19:09 GMT+02:00 Sean Harmer <sean.harmer at kdab.com>:
>
>> On 04/06/2015 14:25, Marc Gilleron wrote:
>> > I tried to set QSG_RENDER_LOOP to "threaded" but didn't noticed any
>> > difference, our application still crashes.
>>
>> Then you need to isolate why it crashes and choose a method to fix it.
>> Some options:
>>
>> * Put your custom rendering into another thread and integrate it into Qt
>> Quick's scene using QQuickFramebufferObject as Kai suggested.
>>
>> * Have your application drive when Qt Quick performs it's rendering by
>> using QQuickRenderControl.
>>
>> * Debug your code to ensure that your rendering code calls makeCurrent()
>> on it's own context whenever it needs to do some GL calls. Apitrace,
>> vogl or similar can help here.
>>
>> * Share the context with Qt Quick so that there is only one context that
>> is always current. This may or may not be possible depending upon the GL
>> requirements of your renderer.
>>
>> Qt Quick is not doing anything naughty here. It's just typical
>> integration of 2 renderers situation where your renderer is making the
>> assumption that no other context will ever be made current. That
>> assumption is being broken by introducing Qt Quick into the picture.
>>
>> Cheers,
>>
>> Sean
>>
>> --
>> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - Qt Experts - Platform-independent software solutions
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150608/bc1a2b76/attachment.html>