0

I am using QQuickControls 2 (SwipeView) with OpenSceneGraph for the 3d rendering. Using QQuickFramebufferObject for the integration.

Since I have introduced a SwipeView, I observe some flickering of my GUI.

I have looked for ages in the doc (it probably sums literally up to weeks) and have absolutely no idea why I have this flickering.

Here is a video of the faulty behavior (flickering starts at ~20s).

And here is my rendering code:

class OsgRenderer : public QQuickFramebufferObject::Renderer
{
public:
    explicit OsgRenderer();

    QOpenGLFramebufferObject *createFramebufferObject(const QSize &size) LC_OVERRIDE;
    void synchronize(QQuickFramebufferObject* item) LC_OVERRIDE;
    void render() LC_OVERRIDE;

protected:
    friend class OsgWindow;

    OsgItem* m_osgItem;
};

void OsgRenderer::render()
{
    assert(m_osgItem);

    if ( !m_osgItem->getViewer() )
        return;

    // Without this line the model is not displayed in the second
    // and subsequent frames.
    QOpenGLContext::currentContext()->functions()->glUseProgram(0);

    // Ask OSG to render.
    m_osgItem->getViewer()->frame(); // WARNING: non-blocking (executed in a thread of its own - in a thread-safe way).

    // Reset OpenGl state for QtQuick.
    m_osgItem->window()->resetOpenGLState();
}

Any idea of where that can come from?

arennuit
  • 855
  • 1
  • 7
  • 23
  • Do you use a timer to update the scene frequently by calling `update` in the QQuickFrameBufferObject? I guess the reason of flickering may due to the fact that Qt Quick automatically reduces the updating frequency of the background items. – Jimmy Chen Aug 22 '17 at 00:35
  • @Jimmy: I indeed call QQuickFramebufferObject::update() (from outside of QQuickFramebufferObject though, not inside it - not sure that makes a big difference anyways). I am not sure I understand this updating frequency difference you mention, how that impacts me and what I can do. Any idea? – arennuit Aug 22 '17 at 12:15

1 Answers1

1

In general it's not a good idea to have QtQuick and OSG both render to the same OpenGL context.
OSG it's keeping its GL state internally between frames, but Qt might modify it from "outside" without notifying osg, and this might cause rendering issues.
A more solid approach is have them use separate (and shared) GL context, and copy the context of the fbo osg redners to in a texture used by Qt.
I've successfully implemented this approach here: https://github.com/rickyviking/qmlosg but haven't tested it with recent versions of QtQuick.
A more up-to-date integration can be found here: https://github.com/podsvirov/osgqtquick

rickyviking
  • 846
  • 6
  • 17
  • QQuickFramebufferObject actually has you render into a separate FBO which is created by the renderer itself. I believe **QQuickFramebufferObject** actually did not exist in 2013 when you wrote your code, though I believe your remark is relevant. I have actually [refined my question in here](https://stackoverflow.com/questions/45821638). – arennuit Aug 22 '17 at 16:12
  • @arennuit you're right that QQuickFramebufferObject did not exist back in 2013, but from what's I've seen that is mainly a container class to execute your rendering instructions. All the concerns about the GL context are still valid, you should adapt the implementation to have it work with this new class – rickyviking Sep 04 '17 at 09:40