<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 28 Sep 2017, at 08:45, Riccardo Corsi <<a href="mailto:riccardo.corsi@kairos3d.it" class="">riccardo.corsi@kairos3d.it</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="gmail_default" style="font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: tahoma, sans-serif;">James can you just confirm that, with the QQuickRenderControl approach, it's no more mandatory to have the main application loop handled by a Qt application class?</div><div class="gmail_default" style="font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: tahoma, sans-serif;"><br class=""></div><div class="gmail_default" style="font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; font-family: tahoma, sans-serif;">At the time when I wrote <a href="https://github.com/rickyviking/qmlosg" target="_blank" style="font-family: arial, sans-serif; font-size: 12.8px;" class="">https://github.com/<wbr class="">rickyviking/qmlosg</a> (probably it was against Qt 4.8) the only option available was to render custom GL stuff within a QtQuick node, and as such I had opted for osgViewer to render into an FBO created on a separate GL context, to avoid any conflict between the GL state used/updated by OSG and the one used by Qt to render its own widgets.</div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">Uh, these two points are unrelated I think!</div><div class=""><br class=""></div><div class="">First thing - it’s never been necessary to have Qt handle the main application loop : so long as you call QCore|Gui\Application ::proccessEvents periodcilly, eg once per frame. That’s true since 4.x</div><div class=""><br class=""></div><div class="">Second thing, rendering in QtQuick 1 vs 2 (i.e Qt 4.x vs Qt5) changed completed, so yes most concepts are different. There’s several different ways to do OSG + QtQuick, some are easy but restrict OSG to rendering in the QtQuick render thread, which still gives overlapping of the main-thread and GL drawing. What I’m trying with the QQuickRenderControl stuff is to make a maximally performance solution for Flightgear which is compatible with /all/ the OSG threading modes. At the moment I’m not sure how well I will succeed.</div><div class=""><br class=""></div><div class="">Alas, no one replied to my message here about running tasks before the rendering starts, but I think I’ve worked out a solution, with some restrictions. I didn’t have time to work on this stuff in the past week, so a little more patience is needed before I can try out my theories.</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">James</div></body></html>