QPropertyAnimation update rate on different devices
-
Hello everyone,
I have a small animation made with QPropertyApplication targeting the Pos()-Property.
With that animation, I let a widget "Fly" in from the side.
The animation is smooth and works fine on my Destop. On my Phone I notice some small issues, but nothing unbearable.
On my Tablet hower, the animation is stuttering like cray.
I connected to the the "value Changed" signal and noticed, my Desktop gets 45 updates in 500 ms where as my tablet has 12 updates in 500 ms. Both for a 800 px movement in y-axis direction.
My question: Is this simply a performance/ hardeware issue of the Tablet/Phone?
Or can I do something against it?
Tablet is an iPad Air 2
It has a resolution of 2.048 pixels but the animation itself says 900 px for top to bottom, so this might be a highdpi -display issue!?
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
Hello everyone,
I have a small animation made with QPropertyApplication targeting the Pos()-Property.
With that animation, I let a widget "Fly" in from the side.
The animation is smooth and works fine on my Destop. On my Phone I notice some small issues, but nothing unbearable.
On my Tablet hower, the animation is stuttering like cray.
I connected to the the "value Changed" signal and noticed, my Desktop gets 45 updates in 500 ms where as my tablet has 12 updates in 500 ms. Both for a 800 px movement in y-axis direction.
My question: Is this simply a performance/ hardeware issue of the Tablet/Phone?
Or can I do something against it?
Tablet is an iPad Air 2
It has a resolution of 2.048 pixels but the animation itself says 900 px for top to bottom, so this might be a highdpi -display issue!?
@J.Hilk
yes it's hardware (CPU) dependant--- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
If you have a question please use the forum so others can benefit from the solution in the future -
@J.Hilk
yes it's hardware (CPU) dependant@raven-worx
I did not want to believe you right away, so I wrote my own animation class. It looks more steady, but it's still a slide show...And here I was dodging the QML-bullet for a few years now...
So either I drop the animation or go the QML route?A few last questions, so I don't go into the wrong direction.
With the assumption that the build in GPU will handle the UI better.- There is no real/good way to simply run a QWidget based UI on the GPU?
- If I simply include a
QQuickVieworQQuickWidgetthat part (the QML one) is automatically done via the GPU or do I have to use a OpenGl Widget or is it not possible at all?
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@raven-worx
I did not want to believe you right away, so I wrote my own animation class. It looks more steady, but it's still a slide show...And here I was dodging the QML-bullet for a few years now...
So either I drop the animation or go the QML route?A few last questions, so I don't go into the wrong direction.
With the assumption that the build in GPU will handle the UI better.- There is no real/good way to simply run a QWidget based UI on the GPU?
- If I simply include a
QQuickVieworQQuickWidgetthat part (the QML one) is automatically done via the GPU or do I have to use a OpenGl Widget or is it not possible at all?
@J.Hilk
it depends what the real bottleneck is. Either is the animation value calculation (CPU) or the drawing itself (GPU).
Where QtWidgets uses the CPU for drawing.--- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
If you have a question please use the forum so others can benefit from the solution in the future -
@J.Hilk
it depends what the real bottleneck is. Either is the animation value calculation (CPU) or the drawing itself (GPU).
Where QtWidgets uses the CPU for drawing.@raven-worx
thanks to my custom class I can say with great amount of certainty, that the drawing the is the bottleneck.I started a QElapsed timer around
move()andrepaint()on my Desktop -> 2 to 10 ms, on the tablet 100 to 340 ms.moveitself takes less than 1ms.Therefore using QQuickView or QQuickWidget for that part of the UI should help, right?
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@raven-worx
thanks to my custom class I can say with great amount of certainty, that the drawing the is the bottleneck.I started a QElapsed timer around
move()andrepaint()on my Desktop -> 2 to 10 ms, on the tablet 100 to 340 ms.moveitself takes less than 1ms.Therefore using QQuickView or QQuickWidget for that part of the UI should help, right?
@J.Hilk
wait, you are usingrepaint()?!--- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
If you have a question please use the forum so others can benefit from the solution in the future -
@J.Hilk
wait, you are usingrepaint()?!@raven-worx normaly I dont.
The Widget should repaint itself in the next cycle after the move command. I just added it to see how long the drawing of the widget takes, via QElapsedTimer.
