Closed Bug 812987 Opened 13 years ago Closed 13 years ago

[SMS] CPU usage is high when message app is opened

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
x86
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:+)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: khu, Unassigned)

References

Details

Attachments

(1 file)

Profiling data
970.79 KB, application/zip
Details
Step to reproduce: 1. Open message app. 2. Check CPU usage with top command. Even there has no messages and I do nothing(no operation is performed), the total CPU usage is around 40% or higher: PID PR CPU% S #THR VSS RSS PCY UID Name 371 0 27% S 11 70180K 21976K fg app_0 /system/b2g/plugin-container 110 0 17% S 37 210620K 64828K fg root /system/b2g/b2g It never goes down, unless the screen goes off, or close message app. I used nightly build(unagi_2012-11-18.zip).
Nominate as bb?. We can discuss if we should flag this as bb+.
blocking-basecamp: --- → ?
By the way, it happened on both Unagi and Otoro.
Does the cpu drop down when you switch apps? Wondering what the user impact here is so that we can decide if this bug is blocking or not.
Flags: needinfo?(khu)
If the app goes to background, the CPU will go down. Just wondering why the CPU is high, because it looks like the app should do nothing, especially when there has no data in the app.
Flags: needinfo?(khu)
We need some profile.sh love here.
Kevin, can you have someone in Taipei grab the profile?
Flags: needinfo?(khu)
Attached file Profiling data —
Hi, I tried to do the profiling twice. Please refer to the attachment for the profiling data. Thank you.
Flags: needinfo?(khu)
Who can interpret the profiling data and see what needs to be fixed here? David, who is the best owner in your opinion?
blocking-basecamp: ? → +
Flags: needinfo?(dscravaglieri)
Here's what the SMS app is doing http://people.mozilla.com/~bgirard/cleopatra/#report=5a606dae45016e5ef65870a0bfc2196bdf5e4c8c There's no JS in the samples, just gecko repainting. It looks like there's an animation that's been left running accidentally.
Component: General → Gaia::SMS
QA Contact: mbarone976
The same thing happens in the Contacts app, btw. I thought animations on opacity:0 divs shouldn't be painted? Should we open a platform bug with a small test case?
Kevin the spinner animation has been removed in bug 816637. Can you check again with the latest gaia build and see if that helps?
(In reply to Tim Taubert [:ttaubert] from comment #10) > The same thing happens in the Contacts app, btw. I thought animations on > opacity:0 divs shouldn't be painted? Should we open a platform bug with a > small test case? You mean animated images or CSS animations? Either way, let's file a followup to fix contacts too.
Flags: needinfo?(dscravaglieri)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12) > (In reply to Tim Taubert [:ttaubert] from comment #10) > > The same thing happens in the Contacts app, btw. I thought animations on > > opacity:0 divs shouldn't be painted? Should we open a platform bug with a > > small test case? > > You mean animated images or CSS animations? The contacts app has a loading overlay infinitely animating/moving an element's background-position property. > Either way, let's file a followup to fix contacts too. Will do. I'll open a platform bug with a test case as well.
(In reply to Tim Taubert [:ttaubert] from comment #13) > (In reply to Chris Jones [:cjones] [:warhammer] from comment #12) > > (In reply to Tim Taubert [:ttaubert] from comment #10) > > > The same thing happens in the Contacts app, btw. I thought animations on > > > opacity:0 divs shouldn't be painted? Should we open a platform bug with a > > > small test case? > > > > You mean animated images or CSS animations? > > The contacts app has a loading overlay infinitely animating/moving an > element's background-position property. Yeah, in general gecko doesn't know a priori when sampling a value of an animation will result in it changing rendering or not. So it has to keep them running. Even elements with opacity:0 can affect rendering (cause overflow which shows scroll bars, for example).
Hi, Vivien, I flashed unagi_2012-11-29.zip and the issue is still there...please refer to the following result from top command: User 52%, System 9%, IOW 11%, IRQ 0% User 166 + Nice 0 + Sys 30 + Idle 85 + IOW 35 + IRQ 0 + SIRQ 0 = 316 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 410 410 0 44% R 74908K 31252K fg app_0 Messages /system/b2g/plugin-container 109 240 0 8% S 198188K 66928K fg root Compositor /system/b2g/b2g 109 109 0 2% S 198188K 66928K fg root b2g /system/b2g/b2g 548 548 0 2% R 1096K 456K fg root top top 410 430 0 1% S 74908K 31252K fg app_0 Timer /system/b2g/plugin-container 410 411 0 0% S 74908K 31252K fg app_0 Chrome_ChildThr /system/b2g/plugin-container 109 243 0 0% S 198188K 66928K fg root Timer /system/b2g/b2g 109 394 0 0% S 198188K 66928K fg root GL updater /system/b2g/b2g 109 232 0 0% S 198188K 66928K fg root Gecko_IOThread /system/b2g/b2g 109 242 0 0% D 198188K 66928K fg root b2g /system/b2g/b2g
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14) > Yeah, in general gecko doesn't know a priori when sampling a value of an > animation will result in it changing rendering or not. So it has to keep > them running. Even elements with opacity:0 can affect rendering (cause > overflow which shows scroll bars, for example). Oh, that totally makes sense. Thank you for clarifying. This may be a little too much for such few use cases but maybe we could just suspend animations that pretty sure won't affect things like overflow, etc. (animating backgrounds, colors and stuff).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12) > Either way, let's file a followup to fix contacts too. Filed bug 816895.
I still see the SMS app using a consistent 37-38% CPU in a build that includes bug 816637.
Strange, it's 0% CPU usage here with all of the test contacts imported.
m( I'll see myself out and try with the SMS app again.
SMS app is idling at 0-1% in thread and edit view for me.
Retested with a fresh build and it's fixed. Not sure what happened ...
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: