Qt empowers productivity across the entire product development lifecycle, from UI design and software development to quality assurance and deployment. Find the solution that best suits your needs.
One of the shortcomings of the Qt Quick API is that despite having a dedicated rendering thread, our animations are always running on the GUI thread.
Running animations outside the application's main thread has the advantage that it greatly reduces jerkyness as operations that block the main thread will not hinder the animations from running.
There are three primary problems hindering us:
Animations update properties and these are tied to QObjects and the meta object system. To avoid threading insanity, we can only read and write these on the GUI thread.
Properties often have bindings in QML, which trigger JavaScript execution which must happen on the GUI thread.
The threaded render loop in the QtQuick library is driven by the GUI thread and does not redraw unless told, so if the GUI is blocked, nothing updates.
A colleague of mine, Marko Niemelä, has been working on an animation system that solves the QObject / QML binding part. His work is in the "animators" directory of the playground repository.
This is not Qt 5.0 material, but maybe we can get it in good shape for 5.1.
Qt 6.7 focuses on the expansion of supported platforms and industry standards. This makes code written with Qt more sustainable and brings more value in Qt as a long-term investment.
