Screenshot leads to lipstick high CPU and battery drain

Is there any insight what the underlying cause might be?

Because that pattern

 property bool something
 opacity: something ? 1 : 0
 Behavior on opacity { FadeAnimator {}}

is used all over the place in many apps and Silica itself. So it potentially affects a lot of things.

@direc85

Do you have a list of places you found need to be modified?

1 Like

The same issue seems to be present in [3.4.0.22] Voicecall-ui uses CPU on the background - #10 by Fuzzillogic albeit a bit more subtle (less drain). Each time I get a call (which is also used as MFA for work) I have to restart the home screen using the utilities, as not to end up with prematurely flat battery.

It’s more common than I thought… I’ve received a plethora of email, SMS, Whisperfish and WhatsApp notifications today, and some of them flash before disappearing, some of them scroll the text quickly to the end and then disappear, an some of them work as expected (slow scroll until the end of the text, until the timeout is reached). I think it something fundamental in the notification system in Silica that causes it, but how on earth to debug such issue?

I’ll give the patch a go, let’s see if it helps…

To get a little prettier output, I applied this modification instead (I modified the patch by hand, so it may not work, but you get the idea):

--- /usr/share/lipstick-jolla-home-qt5/notifications/NotificationActionRow.qml
+++ /usr/share/lipstick-jolla-home-qt5/notifications/NotificationActionRow.qml

@@ -63,7 +63,6 @@ Grid {
     }
 
-    opacity: _active ? 1.0 : 0.0
-    Behavior on opacity { FadeAnimator {}}
+    clip: true
     enabled: _active
 
     Repeater {

Now the animation is somewhat pretty around the “action buttons” of the notifications in the event view as the notification is expanded and shrunk.

Now I really don’t know much about how qml works, but as far as I understand, if you have

Thing { id: thing
    property int count: 1 
}
property bool haveThings: { if ( thing.count > ) { return true } }

haveThings does not update when thing.count changes, unless there is a signal implemented somewhere. Is that correct?

Because the file in question has:

    property int visibleCount: {
    var count = 0
    if (notification) {
        var actions = notification.remoteActions
        for (var i = 0; i < actions.length; i++) {
            var name = actions[i].name
            if (name && name.length > 0 && name !== "default" && name !== "app") {
                count = count + 1
            }
        }
    }
    return count
}

// ... and later

property bool _active: active && visibleCount > 0

// ... and then our suspected-to-be-broken

opacity: _active ? 1.0 : 0.0
Behavior on opacity { FadeAnimator {}}
enabled: _active

Is it possible that visibleCount doesn’t update correctly/reliably?

In your Thing example, the count is a property , so a signal is automatically associated to it. Using it in a JavaScript piece of code makes this piece of code reevaluated if count is changed. I mean when this piece of JavaScript is used as a binding to something, like in your example.

1 Like

Thank you for clarifying!

Just to complete my education: if Thing is implemented by me in C++ and I do not emit a signal on changes in my code, then it will not reevaluate, correct?

Indeed. My reply was corresponding to your snippet in pure QML. Thing can be implemented in C++ with count declared as a property with a READ function and a CHANGED signal. And last be not least, the latter signal must be emitted each time the former read function would evaluate to a different value. Then, it would behave as described with JavaScript piece of code reevaluated each time count is changing.

1 Like

After applying this, I didn’t get any CPU drains from lipstick, but after upgrading to 4.4.0.64, which reverted it, I started getting them again… Two times today already.

It’s really a hit-and-miss work trying to pin this down… Any ideas making it easier are miat appreciated!