QPropertyAnimation update rate on different devices
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!?
yes it's hardware (CPU) dependant
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
QQuickWidgetthat 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?
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.
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
repaint()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?
wait, you are using
@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.