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.gille...@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.har...@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.har...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
