Important: Please read the Qt Code of Conduct -

QPropertyAnimation update rate on different devices

  • Moderators

    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!?

  • Moderators

    yes it's hardware (CPU) dependant

  • Moderators

    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 QQuickView or QQuickWidget that 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?

  • Moderators

    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.

  • Moderators

    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() and repaint() on my Desktop -> 2 to 10 ms, on the tablet 100 to 340 ms. move itself takes less than 1ms.

    Therefore using QQuickView or QQuickWidget for that part of the UI should help, right?

  • Moderators

    wait, you are using repaint()?!

  • Moderators

    @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.

Log in to reply