[osg-users] Qt Quick and Android

[James Turner]

> On 28 Sep 2017, at 08:45, Riccardo Corsi <riccardo.corsi at kairos3d.it> wrote:
> 
> 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?
> 
> At the time when I wrote https://github.com/rickyviking/qmlosg <https://github.com/rickyviking/qmlosg> (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.
> 

Uh, these two points are unrelated I think!

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

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.

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.

Kind regards,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170929/e84f304d/attachment.html>