[Interest] QML and OpenGL conflicts

[Marc Gilleron]

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/20150605/8c3ea44a/attachment.html>