Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QPropertyAnimations tearing and/or stuttering
I'm doing a few experiments with QPropertyAnimations in Qt5.6, but so far have been unable to get acceptable results. For testing puposes, my test just moves QLabel (cotaining a square pixmap) diagonally from the upper right to the lower left corner. I tested this running on both Win10 and Linux (Ubuntu 16.04 running lxde display manager) on an intel J1800 based board with on-board graphics.
On both systems the movement itself is jerky, as if it was stopping and very quickly starting again several times. The Win10 version addtionally shows problems with the lower border of the moving square. It looks as if the lowest few lines get drawn before the rest of the square follows.
On Linux, the left and right sides of the square seem to get slowly redrawn every few pixels or so. You can actually witness the left- or rightmost few columns to get visibly redrawn from top to bottom (in fraction of a second, but nevertheless visible.
My question is: is this normal? Is this the best a movement via QPropertyAnimation can look? Or can I do something do improve the quality of the animation?
I can provide my test source if necessary - but it's really just a QApplication opening a QDialog with a single QLabel (containing a QPixmap) which is QPropertyAnimated.
Any help is appreciated.
I have only tested a little on Desktop class pc and movement was smooth.
It would however be great with a ready to run sample so we can test if your
use case do in fact "jerk" or its related to the gfx power of the boards.
Heseltine last edited by Heseltine
No problem, I uploaded the Project to WeTransfer, including the two dummy pictures used. They have to be copied to the build directory in order to run the project from within Qt creator.
Super with the videos :)
At 1920x1200, its not smooth at all here. (Gamer spec pc)
The "rect" is very jerky when moving.
I will play around with it and see if I can get a clue.
I agree. it does not run smooth.
Im not sure if using image makes it heavier but I was not able to make it look smooth
regardless of the settings.
Okay, thanks for trying. That way, I know that I needn't bother myself with my low-end machine. It looks to me like the property changes aren't properly synced with the display refresh, or maybe Qt doesn't use double buffering for these operations.
I guess I'll have to try out Qt's OpenGL API, then - even though I only need a few simple 2D zooms and transitions. Is there any way to draw/animate a QLabel (or something like that) with text and/or images using QtOpenGL?
Well for small transitions it looks fine but across fullscreen
u really see the stutter. it looks better with other ease curve but
the default (stright) was just awful. It could be something in Qt5.7 as
i remember it smoother in 5.5.
Have you considered QML ?
Its openGL powered and can transit etc out of the box.
No, I had not considered QML before, but that looks like it might be doing exaclty what I'm looking for.
We have a kiosk system originally written in Standard C++ using the de-facto defunct DirectFB API that full-screen displays a bunch of infos on a LCD monitor (no touch screen, user input mainly consists of two hw buttons to flip through the pages). We want to move the program to Qt and add a few simple transitions in the process to make the display graphics look a bit less outdated.
If it's possible to combine these QML objects with standard C++ program logic (there are a few additional threads in the application for data acquistion etc.), that would probably be the easiest way to proceed. And from what I could find out from glancing at the QML docs, combining QML and classical Qt C++ shouldn't be a problem.
Thanks for the tip!
Combining QML with c++ is very easy and
also encouraged in terms of QML for interface, c++ for backbone.
That gives very nice separation between logic and presentation.
The only concern I have for your use as kiosk system
is that QML requires pretty good opengl support on target and that can sometimes be a issue on
older Atom boards etc.
Yeah, peformance might be an issue (though a handfull of simple QtOpenGLWidget tests I tried out on the machine ran smoothly).
I'm going to try out a few of the examples from your link to the QML tutorial to test the performance before moving any code to QML.
though a handfull of simple QtOpenGLWidget tests I tried out on the machine ran smoothly
With regular widgets you do software rendering through the OS's GUI API so there's little wonder you get a terrible performance hit on complex drawings (like transition effects and such). If you really need smooth and cool animations/transitions then I suggest following @mrjj's advice and go with QML.