One of the drawbacks of Qt Quick API is that although rendering is performed in a dedicated stream, nevertheless, our animation always works in a stream of a graphical user interface.
Running an animation outside the main application flow has the advantage of significantly reducing the impact of resource-intensive tasks on animation, which usually block the main flow and lead to animation delays.
There are three main problems that prevent us from rendering the animation in a separate thread:
The animation is updated when properties change. Properties are part of a QObject and a system of meta-objects. To avoid insanity with threads, we are only allowed to read and write these properties in a stream of a graphical user interface.
Properties often have bindings and associations in QML that cause JavaScript code when certain events occur, which must also be executed in a GUI thread.
The render cycle in the QtQuick library is tied to a GUI thread, and therefore, when this thread is blocked, the animation is not updated.
As it was written in my previous post, this patch fixes the third problem, but leaves open the question of accessing QObject and pausing execution of JavaScript. ')
My colleague, Marko Niemelä, is working on an animation system that solves the QObject / QML communication problem. His work with the property "animations" is in the playground sandbox.
This is not Qt 5.0 functionality, but maybe we will see it in Qt 5.1.