An unusual effect of a component over another in a QML mobile app

[J.Hilk]

hi @tomy

so the slowdown issue is also present, when you de no checks and simply move the rackets?

You know, this may simply an issue with your hardware - Android 4.4.2 is rather old, KitKat was released 2013. -

QML will try to do a redraw each time y of the racket changes. Which may overtax your gpu. I don't know if there's a way to limit the redraw attempts of QML.

What could work is replacing Racket from a QML file with a custom QQuickDrawItem, that way you actually have to manage the drawing yourself and you could limit the amount per seconds that way.

[ODБOï]

@J.Hilk said in An unusual effect of a component over another in a QML mobile app:

You know, this may simply an issue with your hardware - Android 4.4.2 is rather old, KitKat was released 2013. -

This issue is present with w7 pc : intel i5 - Gtx1060 6Go

[J.Hilk]

@LeLev

well It's a performance issue,

if I run this on my Mac it's smooth enough, if I run it on my phone it's smooth, if I run it on an iPhone Simulator it's stuttering.

I was somewhat able to tweak it by doing the following changes:

import QtQuick 2.12
import QtQuick.Window 2.12
import QtQuick.Controls 2.5

Window {
    id: window
    visible: true
    width: 1000; height: 800
    color: "gray"

    // The components
    // --------------

    Timer {   // This timer's job is merely moving the ball
         id: gameTick
         interval: 40; repeat: true; running: true

         property int count: 0

    onTriggered: {
        //Update ball
         ball.x +=  2/*0.88*/
         ball.y +=  2/*0.88*/

        //Update rackets

        count++;

        if(count % 4 == 0){
            console.log(count)
            if(mAreaRightRacket.pressed){
                redRacket.y = mAreaRightRacket.mouseY - redRacket.height/2
            }

            if(mAreaLeftRacket.pressed){
                blackRacket.y = mAreaLeftRacket.mouseY - blackRacket.height/2
            }
        }

       }
    }

    Rectangle {
        id: table
        anchors.fill: parent
        anchors.margins: 10
        y: 10
        anchors.horizontalCenter: parent.horizontalCenter
        color: "royalblue"
    }
    Racket {
        id: blackRacket
        anchors.left: table.left
        anchors.leftMargin: width * 2
        y: table.height / 2
        color: "black"

//        Behavior on y {
//            NumberAnimation{duration: 120}
//        }
    }
    Racket {
        id: redRacket
        anchors.right: table.right
        anchors.rightMargin: width * 2
        y: table.height / 2
        color: "red"
    }
    Ball {
        id: ball
        x: 150
        y: 150
    }

    MouseArea{
        id:mAreaRightRacket
        anchors.top: parent.top
        anchors.bottom: parent.bottom
        width: redRacket.width
        anchors.horizontalCenter: redRacket.horizontalCenter
    }

    MouseArea {
        id: mAreaLeftRacket
        anchors.top: parent.top
        anchors.bottom: parent.bottom
        width: blackRacket.width
        anchors.horizontalCenter: blackRacket.horizontalCenter
    }
}

[ODБOï]

@J.Hilk said in An unusual effect of a component over another in a QML mobile app:

well It's a performance issue

Yes. It looks like a performance issue to me also,
but hardwere performance or qtquick performance/efficiency
How my PC can run modern 3D games in ultra, rendering 60fps and 'freeze' because of a simple app like this ?

[tomy]

It actually is not a performance issue. I have tested this simple program on my tablet. OK it's old and it might be considered as the real rationale behind the issue. Yesterday, I sent its APK file in three different versions (Arm 7a, Arm 8a and X86) to one of my friends whose smartphone is very new running an up to date Android OS. All three had the same issue on that too!

The changes offered in post #4 solve the issue but with the price of damaging another part!
Racket movements won't affect the ball's speed (good) but the racket itself doesn't follow the finger's movement of the user steadily and fast enough (bad) which previously, in the first code, wasn't that way and was working fine.

That's so strange to me. QML looks very strange. Look at the code, it's totally about only 30 lines of code. 30 lines!
When there is almost no way to discover the problem of such a simple program in QML and solve it, what a language is QML!! Will you define that for me, please??

[J.Hilk]

@tomy

question, did you set QtCreeator to release build? And did you sign your application.

There's a huge performance difference between debug and release, and I think you need to sign the app for it to be a true release build, IIRC.

[tomy]

@J.Hilk
Hi, Sorry for the delay.

Yes, I tested the app using the Release mode on both Desktop and the Android device. On both it's behaving like what I described in the prior post. :|

Anyways, the initial problem with the ball -- as described in the first post of the thread -- is solved by using onFrameSwapped: , to move the ball, instead of the Timer. Now the new problem is to find a way to measure how fast is the racket moving when hitting the ball. :(

And did you sign your application.

I don't know what the sign is? What do you mean please?

[J.Hilk]

@tomy said in An unusual effect of a component over another in a QML mobile app:

I don't know what the sign is? What do you mean please?

https://developer.android.com/studio/publish/app-signing

[tomy]

@J.Hilk
I'm curious how signing an app can affect the way its code behaves! :(

[J.Hilk]

Hi @tomy , I'm speculating here, as I have no idea what google is actually doing with all it's stuff.

But from what I noticed, reading through the compile log is, that a lot of debug related stuff is still copied into the apk, as long as it's not signed. In fact so much, that one of my apps is nearly halved in size after signing.

A reasonable conclusion would be, that there can very well be a difference in the apk & performance between signed and unsigned.

[tomy]

Hallo @J.Hilk,

a lot of debug related stuff is still copied into the apk, as long as it's not signed. In fact so much, that one of my apps is nearly halved in size after signing.
A reasonable conclusion would be, that there can very well be a difference in the apk & performance between signed and unsigned.

That is good info, thanks. Almost always the apps I finally create APK files for them have both the saame size in Release and Debug mode. That could be a reason for that. I also think it's the same for both Qt and QML apps (not only QML), right?

I doubt, however, if not-signing an app will have influence on it in Release, i.e., all the garbage added to the not-signed app when building is done for the Debug mode. Hence, we finally have two option, signing the app and enjoy using it, or not signing and enjoying it in Release.

One more thing, from all experience I have through testing several apps I've been tackling, both modes have had the same behavior when testing.

Also, the two problems with the app are worked out now this way:

• Using onFrameSwapped instead of Timer to solve the problem with he ball's movement speed when moving the rackets
• Obtaining the velocity of the racket for each movement of it and applying it when hitting the ball to set the speed of the ball then.
  :)