This should still be investigated by someone from Jolla IMO
The high CPU item still exists on 4.2.0.21 final, and the patch is needed to avoid it.
I unmarked the solution as to make it clear that the root bug still exists.
1 Like
Is the patch @vlagged linked already in upstream? I have a Xperia II 10 with SailfishOS 4.2.0.21, and I’m suffering from the same bug as @direc85 is.
Looks like Patchmanager doesn’t work with AArch64 yet. How can I apply the patch until it gets mainlined or Patchmanager gets updated?
There’s a prerelease version of patchmanager 3.1 in chum:testing[1] - you can try that before it hits Openrepos
[1] Show sailfishos:chum:testing / patchmanager - SailfishOS Open Build Service
1 Like
Thanks! Though I already managed to apply it manually.
I’m not familiar with OBS on SailfishOS. I guess I’ll have to look into it later.
This still affects at least XA2 Ultra with SFOS 4.4 EA
Thanks for reporting this, and for checking it on the latest release.
I’ve created an internal bug report about it and tagged it as “tracked”.
2 Likes
Thanks for creating a ticket for this!
I do have to add that for handful of times, the latest being just today, I have ran into similar issue on my X10II (lipstick using a lot of cpu) without a screenshot being involved. It was fixed by restarting home screen. So, it could be common with certain notifications, or unrelated… I’ll try to reproduce this with the screenshot in a few days time.
Thanks for that. Any further info that we can use to refine the bug report would be helpful.
The contents of the patch, just for reference for those who do not use patchmanager:
--- /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 {}}
enabled: _active
Repeater {
3 Likes
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.
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!