AnsweredAssumed Answered

Qt Quick responsiveness and Open GL ES 2.0 conflict on iMX6q with Vivante

Question asked by Andrea Tessadri on Apr 30, 2015
Latest reply on May 7, 2015 by Andrea Tessadri

I am developing an industrial video application on iMX6q equipped with Vivante GPU.

My problem is that, since I use directly the GPU for heavy image processing, I don't have a responsive GUI base on Qt Quick 2.

Qt Quick is based on OpenGL ES that is exactly the same API I am using for the video processing, so the GPU is quite never free to render Qt animations.


I am trying to solve the problem using semaphores in order to stop video processing when there is a touch on the GUI (touch screen display).

The result is as follow:

1) the touch is immediatly taken from the Qt Quick GUI (MouseArea onPressed) and I am able to stop video processing using sem_wait()

2) since the onPressed action triggers a state change for the button on the GUI, the related Transition animation is not fluent even if there is no more video processing ongoing

3) I used the SequentialAnimation to trigger a script at the end on the Transition in order to restart the video processing but it seems that when the script is invoked the animation was not finished


Here is the part of my QML code

MouseArea {
        id: mouseArea
        anchors.fill: parent
        hoverEnabled: true

        onPressed: {
            container.state = "active";
        onReleased: {
            container.state = "";

states: State {
        name: "active";
        PropertyChanges { target: content; color: "#FCFFF5"; scale: 1.1 }

    transitions: Transition {
        SequentialAnimation {
            NumberAnimation { properties: "scale"; duration: 100 }
            ScriptAction { script: releaseGuiSem(); }

    function releaseGuiSem() {;


Since the Qt GUI is based on 2 threads (GUI thread + Rendering thread) I would like to know how to understand when the animation embedded in the transition is really finished.

Is there any signal to catch ?


Another issue is to understand when a transition animation starts.

In my case, sometimes, I don't see the part of the animation related to state transition "normal" -> "active" because the call to semaGuiEvents.wait() stops the GUI thread waiting for the video processing to stop also (the video application will release the semaphore and it will stop again letting the Qt to go).




   Andrew (Milan, Italy)