Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Forum Updated on Feb 6th

    Unsolved Something drains battery... ListView is a suspect.

    QML and Qt Quick
    5
    13
    546
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      Gourmet last edited by Gourmet

      I often see message about my currently developed app drains battery on smartphone. My code does nothing when app is idle. It just waits in the Qt message loop as obvious. On the screen app shows complex ListView with 18 different size Texts in each Rectangle. There is MouseArea on each Rectangle too. List is large, scrollable and has scrollbar. And background colors in Rectangles are different depending from some date-time conditions. And there are several other windows on top of it but most time they are hidden (by hide() method exactly). I did not yet profiling but may be anybody here did. What is known about processor consuming by QML interface elements and it's optimization? I am seriously worry about this. If my application will drain user's batteries while being idle - the Google will remove my app from GP.

      J.Hilk JKSH 2 Replies Last reply Reply Quote 0
      • J.Hilk
        J.Hilk Moderators @Gourmet last edited by J.Hilk

        hi @Gourmet

        I have an app in the store, that has a multitude of ListViews in them one is almost always on display + continues data exchange via Bluetooth. Each time a package is received a new one is requested.

        I have no problem at all with battery draining warnings. In fact this app is a recreation of one of our old apps (made in pure JS of all things) and that one got the warning. The one made in Qt does not.

        So ListView is 99% not the issue here. You should investigate your code you're most likely doing processor heavy tasks somewhere.

        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct

        Qt Needs YOUR vote: https://bugreports.qt.io/browse/QTQAINFRA-4121


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        1 Reply Last reply Reply Quote 4
        • G
          Gourmet last edited by Gourmet

          I do not know how exactly QML engine works. But I have noticed some interesting thing. In my QML file for this ListView I added following option - if current system time is greater or lower than time value Moment in item, then item's rectangle has different background color. It's just like:

              ListView {
                  id: lView
                  property date today: new Date()
          
                  delegate: Rectangle {
                      color: modelData.Moment < lView.today ? "gold" : "yellow"
          

          In my code I do not refresh view. Moment is some time changed only by user and nothing else. But I was surprised - right now after system time comes over Moment - then Rectangle changes it's color. That means - ListView or QML engine or QQuickWidget - somebody of them permanently refreshes it's view. This is definitely processor consuming action.

          JonB fcarney 2 Replies Last reply Reply Quote 0
          • JonB
            JonB @Gourmet last edited by

            @Gourmet said in Something drains battery... ListView is a suspect.:

            Moment is some time changed only by user and nothing else.
            But I was surprised - right now after system time comes over Moment

            What does this mean? Are you saying modelData.Moment changes, or new Date() changes or what?

            G 1 Reply Last reply Reply Quote 0
            • G
              Gourmet @JonB last edited by

              @JonB nope... After written above I've made some tests - it works different. I must make more experiments... Right now it's not clearly visible how it works.

              1 Reply Last reply Reply Quote 0
              • JKSH
                JKSH Moderators @Gourmet last edited by

                @Gourmet said in Something drains battery... ListView is a suspect.:

                I did not yet profiling but may be anybody here did. What is known about processor consuming by QML interface elements and it's optimization?

                I haven't encountered anything like this myself, but I highly recommend profiling.

                Here are some other tips that might help: https://doc.qt.io/qt-5/qtquick-performance.html

                Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                1 Reply Last reply Reply Quote 2
                • fcarney
                  fcarney @Gourmet last edited by

                  @Gourmet said in Something drains battery... ListView is a suspect.:

                  That means - ListView or QML engine or QQuickWidget - somebody of them permanently refreshes it's view. This is definitely processor consuming action.

                  This changes because you modified the value of a property. Of course it will change. That is how it is designed. It doesn't mean that QML is sitting there checking for changes constantly.

                  Now, is modelData or any other exposed C++ objects constantly changing values that are assigned to properties in QML? If so then it will drain battery.

                  C++ is a perfectly valid school of magic.

                  G 1 Reply Last reply Reply Quote 2
                  • G
                    Gourmet @fcarney last edited by Gourmet

                    @fcarney said in Something drains battery... ListView is a suspect.:

                    is modelData or any other exposed C++ objects constantly changing values that are assigned to properties in QML?

                    Constantlty - no. In background - no. My application does nothing in background. What is most interesting - I have many other apps made on the almost same internal design like this one. About difference I'll tell little later. Those apps DO constantly work - they show music visualizations with frame rate 15 FPS. Of course they do calculations in background and they refresh screen part. But Android NEVER told they drain battery. The only one important difference of those apps from this one is - they DON'T use QML. They are completely QWidget-s based.

                    1 Reply Last reply Reply Quote 0
                    • fcarney
                      fcarney last edited by

                      @Gourmet said in Something drains battery... ListView is a suspect.:

                      If my application will drain user's batteries while being idle - the Google will remove my app from GP.

                      Could it be a false positive? Could Google be not liking the content of the app and are using this as an excuse to target the app (Google, despite claims, is not impartial.)? Are users of competing products attacking your app by saying it causes a problem that it does not?

                      C++ is a perfectly valid school of magic.

                      G 1 Reply Last reply Reply Quote 0
                      • G
                        Gourmet @fcarney last edited by

                        @fcarney No. No. No. Google has rule about battery consuming applications. App must not actively drain battery being idle. Otherwise Google can remove it on this reason.

                        But it is possible to particularly solve this problem with AndroidManifest.xml setting

                        <meta-data android:name="android.app.background_running" android:value="false" />
                        

                        Unfortunately in this case application won't be able check for it's location on GPS and send notification when it reaches targeted point. But my apps must do this. It is one of their important function.

                        JonB 1 Reply Last reply Reply Quote 0
                        • JKSH
                          JKSH Moderators last edited by

                          @Gourmet Profile it.

                          Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                          1 Reply Last reply Reply Quote 3
                          • JonB
                            JonB @Gourmet last edited by

                            @Gourmet
                            As everybody else says here, QML does not sit there updating/refreshing because it has nothing else to do. If you truly suspect ListView, I suggest you create a tiny, standalone QML containing just that and see how it behaves battery-wise.

                            1 Reply Last reply Reply Quote 3
                            • fcarney
                              fcarney last edited by

                              Just for an example of what can cause CPU load in QML. I created some Text in a delegate. When I have a winning condition in my game I rotate some of the text back and forth. If I do this alone the CPU usage will go from 0% to 2% while the Text is rotating. If I give it a drop shadow and/or a gradient and rotate the CPU jumps to eat a whole core. So 15% CPU on my laptop. As soon as I stop the animation it goes back to the 0% or nearly 0. This has made me rethink using certain animations in QML except for maybe transitions. I tested some of the line drawing with opengl and the shape based drawing in QML and those consume magnitudes less of cycles. So I learned this weekend you have to be really careful what parts of QML you use and how you use it. Trial and error I guess.

                              @Gourmet maybe not useful for your current problem. I hope you can track it down.

                              C++ is a perfectly valid school of magic.

                              1 Reply Last reply Reply Quote 3
                              • First post
                                Last post