An unusual effect of a component over another in a QML mobile app
-
Hi all,
I tested the QML program below on an Android device (a tablet running Android 4.4.2). The problem is that, when rackets are not moving the ball moves smoothly (and it’s OK), but when I move either racket, it affects the speed of the ball, strangely, and reduces that!
These two must be independent in terms of movement and speed, but in effect this issue takes place. I don’t know why.What could be the source of the issue and how to remedy that, please?
Or how to change the code to have the same behavior but with no problem?Ball.qml
:import QtQuick 2.12 Rectangle { width: 18; height: 18 color: "white" radius: width/2 Timer { // This timer's job is merely moving the ball id: timer interval: 22; repeat: true; running: true onTriggered: { parent.x += 0.88 parent.y += 0.88 } } }
Racket.aml
:import QtQuick 2.12 Rectangle { id: root width: 15; height: 65 MouseArea { anchors.fill: root drag.target: root drag.axis: Drag.YAxis drag.minimumY: table.y drag.maximumY: table.height - root.height - 10 } }
main.qml
: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 // -------------- 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" } Racket { id: redRacket anchors.right: table.right anchors.rightMargin: width * 2 y: table.height / 2 color: "red" } Ball { id: ball x: 150 y: 150 } }
-
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.
-
@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
-
@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 } }
-
@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 ? -
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
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?
-
@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?
-
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.
-
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.
:)