⚠️ Forum Maintenance: Feb 6th, 8am - 14pm (UTC+2)

Animation on y seems to interfere with onYChanged signal / x manipulation

  • Hi,
    I am experiencing frequent (but not 100% reproducible, more like 30%-40%) crashs when I try to add a speed- and random-based x-movement to my linear y-animation.

    I am trying to achieve a "falling glitter"-effect. I have a Repeater, that produces a number of little stars. Each star is a Canvas QML type. Here's what I do:

            Canvas {
                id: rootCanvas
                width: 20
                height: 28
                visible: solvedRepeater.contentVisible
                property real startY: 0
                property real xSpeed: 0
                onVisibleChanged: {
                    if (visible) {
                        rootCanvas.x =   Math.random()*appWindow.width
                        rootCanvas.y = (1.5 * Math.random()*appWindow.height) - appWindow.height
                        rootCanvas.rotation = Math.random()*360
                        startY = y
                ParallelAnimation {
                    id: parallelAnimationSolved
                    running: false
                    NumberAnimation {
                        target: rootCanvas
                        property: "y"
                        to: 2 * appWindow.height+startY;
                        duration: 3000 + (Math.random()*1000 - 500) // different tempos
                        running: false
                    RotationAnimation {
                        direction: RotationAnimation.Clockwise
                        target: rootCanvas
                        to: 360*Math.random() * 7;
                        running: false;
                        duration: yNumberAnimation.duration
                onYChanged: {
                    xSpeed += Math.random()*.4 - .2
                    x += xSpeed;
                onPaint: {
                    var ctx = getContext("2d")
                    ctx.lineWidth = 1
                    ctx.strokeStyle = "gold"
                    // [...]  many more "lineTo"s...
                    ctx.fillStyle = "gold" 

    The code doesn't seem to crash, as long as I out-comment the onYChanged: {…} part.

    I've had experienced such crashes even more often, when both parts of the ParallelAnimation were independent NumberAnimations. After putting both in the ParallelAnimation it improved, but the problem persists as long as the onYChanged-section is not commented out.

    I haven't found anything in the docs about not being allowed to touch the animated property for reading or to alter a different property - and I have no idea how to implement a dynamic and random-driven xSpeed within a QML Animation (that ultimately could be put in the ParallelAnimation).

    Any ideas what I can do?
    [Qt5.11.2, crashes happen on Windows and Android]

  • Qt Champions 2017

    Not sure why it crashes. How about adding the animation for x with same duration as y. Do you have small sample which we can see and suggest ?

  • Qt Champions 2018

  • @dheerendra : Thank you very much for your help. I would have thought to hit a limitation of some kind, but when you didn't see a problem in the code I tried to look for different reasons for the crash, and it seems I have found one:

    The use of the animation seems to have revealed a previously undiscovered ownership problem that I've probably had - or at least have made it more probable to surface and crash the application.

    Since I've added the "setObjectOwnership" line below, the crash didn't (yet) occur again:

    void *QmlGenerator::createEmptyEquation(QQuickItem *loader) {
        loader->setProperty("sourceComponent",  QVariant());
        m_engine->setObjectOwnership(loader, QQmlEngine::CppOwnership);    //[Edit: correction]

    I am still not 100% sure to have found the actual bug, but as I meanwhile did encounter the very same crash without any animation (only once, but it was there), I am quite sure that this question can be closed.

    [Edit for posterity: Since I have taken ownership to Cpp and carefully check which Object I need to ->deleteLater() the bug is gone. Yeeha.]

    Thank you very much again - your answer brought me to doubt my (false) assumtpion.

  • @GrecKo Thank you, that does indeed look very interesting. I will dig into that, regardless of this (probably solved) case.

Log in to reply