Steps: 1) Boot master/m-c buri 2) Long press on an app to enter the "move apps or delete apps" mode. Little red x's appear on the apps. 3) adb shell top -m 5 Expected: User can still easily swipe between pages while in this new mode. Device is responsive. Top shows minimal CPU usage while idle. Actual: The device is very slow to swipe between pages. Lots of jank. Top shows > 50% CPU usage while idle. gaia: d94ce19fda6f4384d4dfbdf97c7b46b75b993c46 gecko: 45ba19361b97

Can we confirm this doesn't reproduce on 1.4?

Issue is reproducible on today's 1.4. Copied and pasted one instance of results: User 50%, System 10%, IOW 23%, IRQ 0% User 125 + Nice 31 + Sys 33 + Idle 46 + IOW 74 + IRQ 0 + SIRQ 1 = 310 PID PR CPU% S #THR VSS RSS PCY UID Name 137 0 50% S 37 177968K 67880K fg root /system/b2g/b2g 370 0 5% S 12 166424K 30880K fg app_370 /system/b2g/plugin-container 19 0 2% S 1 0K 0K fg root kworker/0:1 495 0 1% R 1 1028K 420K fg root top 77 0 1% S 1 0K 0K fg root kworker/0:2 Tested on: Device: Buri 1.4 MOZ BuildID: 20140418000201 Gaia: 97b8f9a0a2bd82572422dd84f84016df0e7f56c8 Gecko: e43434b6dd4e Version: 30.0a2 Firmware Version: v1.2-device.cfg

Ben - Does comment 2's testing match the bug you reported here? Just want to double check.

In my local test, it's total CPU usage is over 80%: User 85%, System 14%, IOW 0%, IRQ 0% User 83 + Nice 192 + Sys 45 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 320 PID TID PR CPU% S VSS RSS PCY UID Thread Proc 362 362 0 58% R 69848K 26568K fg app_362 Homescreen /system/b2g/plugin-container 83 322 0 24% S 138888K 44468K fg root Compositor /system/b2g/b2g 376 376 0 4% S 0K 0K unk root irq/181-wlan0 357 357 0 2% R 1056K 408K fg root top top 83 352 0 1% S 138888K 44468K fg root Compositor /system/b2g/b2g 61 61 0 1% S 0K 0K fg root kworker/u:3 83 353 0 1% S 138888K 44468K fg root Compositor /system/b2g/b2g 83 302 0 0% S 138888K 44468K fg root Gecko_IOThread /system/b2g/b2g 57 57 0 0% S 0K 0K fg root kworker/u:1 362 363 0 0% S 69848K 26568K fg app_362 Chrome_ChildThr /system/b2g/plugin-container 362 392 0 0% S 69848K 26568K fg app_362 Timer /system/b2g/plugin-container 85 85 0 0% S 768K 356K fg root oom-msg-logger /system/bin/sh 5 5 0 0% S 0K 0K fg root kworker/u:0 72 72 0 0% S 0K 0K fg root yaffs-bg-1 324 324 0 0% S 0K 0K fg root kworker/0:2 60% for app main, 25% for compositor. In the profiler result, it seems that the shrinking animation eat too much CPU.

I tried it on my v1.1 helix and the swipe performance is kind of lackluster as well. I guess this isn't a regression. It would be nice to improve this, though.

I've tried a number of patches on the Gaia side to try and combat this, will-change, translateZ(0), optimizing selectors, changing CSS properties and hierarchies and none had any effect on resolving this. Even applying the patch used to improve the responsiveness used in bug 974381 had no effect. I do think that this issue is occurring somewhere on the Gecko side. I have created a profile [1] which logs going into edit mode on the homescreen. The only thing that really stood out for me was the amount of time spent in compositing. [1] https://people.mozilla.org/~bgirard/cleopatra/#report=9b08c9a26905e8f9d7756657f4e3f10a71705c7c Christian or Vivien, do you know who could take a look at this from the Gecko side?

Hi Eli, I am pretty sure that Vivien knows who could take a look at that. Sorry for this but I don't have idea

IIRC correctly this 'all icons are animated at the same time' issue has been evoked last week. And I'm pretty sure to remember that Roc says that there are some stuffs that can be done on the platform side to reduce the number of paint calls which may help here.

How many layers have we got in this case? When Mason and I looked into this, the layer tree was OK, about 3x as many app-icon layers as visible on the screen, which sounds correct. And it was only about 36 layers which should be OK. It looks like the stacks in the profile are incomplete, just the labels without the stack samples. It would be helpful to have the complete stacks. Also, it's not clear which time range in the profile is relevant, can you tell us that? I have a feeling this is a compositor performance issue. We should only be compositing the visible layers, so only about 12-16 icons I guess, and I would have expected that to work fine. Hopefully Milan can find someone to look into this?

Benoit is already looking at this in the context of another bug - "how many layers is too many".

Benoit, would you be able to take ownership of this bug? I have exhausted our resources from the Gaia side.

Benoit is looking at the "how many layers are too many" issue, which may be related to this and may contain a fix once we get to it. This is different from taking ownership of this bug, that's a separate topic.

By the way, why is this blocking 2.0? It's useful to record that info when the decision is made.

Milan, at this point I am looking for someone to take ownership of this bug as there is nothing more I can do from this end, so if you have someone that can look into it even in a future sprint so it doesn't get lost would be helpful.

(In reply to Milan Sreckovic [:milan] from comment #14) > By the way, why is this blocking 2.0? It's useful to record that info when > the decision is made. See comment 0, comment 2, and comment 4 for confirmation of high CPU usage (50% - 80%) which is reason enough to block. Slow panning is an issue I'd expect the Graphics team would consider release blocking.

Slow panning has also been addressed by bug 974381.

Eli, understood what you're looking for. Mike - this is not general panning, this is panning while editing, and the matching 1.4 bug just dropped the +. Anyway, if you don't mind waiting for the investigation to finish on the "number of layers", it may shed more light on this bug.

Thanks Milan. We're (FxOS Perf) okay with waiting on Benoit's "number of layers" investigation's results (comment 13). Sounds like we're in agreement on 2.0 blocking so I'm assigning this you to find an owner or close once Benoit's results are available.

I don't have numbers yet for the number of layers but we have a budget of 100 trivial color draw calls to stay at 60 FPS. That's a hard cap. I need to investigate the number of textured layers and the number of gralloc layers. I expect the latter to be much lower than 100. Compositor benchmark being introduced part of bug 1014042.

This might be lower priority now if we switch to the new homescreen for 2.0.

QA Wanted to see if this happens with the vertical homescreen.

Here are the numbers for testing on the vertical homescreen: Actively MOVING an app icon around on the screen: User 51%, System 43%, IOW 0%, IRQ 0% User 130 + Nice 188 + Sys 270 + Idle 32 + IOW 2 + IRQ 0 + SIRQ 1 = 623 PID PR CPU% S #THR VSS RSS PCY UID Name 301 1 60% S 50 229548K 95488K root /system/b2g/b2g 1055 0 29% S 15 121388K 47232K u0_a1055 /system/b2g/plugin-container 2448 0 1% R 1 1236K 564K root top 96 0 0% S 1 0K 0K root ksmd 2443 0 0% S 1 0K 0K root kworker/u:1 Sitting IDLE in edit mode: User 18%, System 40%, IOW 0%, IRQ 0% User 105 + Nice 6 + Sys 240 + Idle 240 + IOW 0 + IRQ 0 + SIRQ 0 = 591 PID PR CPU% S #THR VSS RSS PCY UID Name 301 1 61% S 49 213320K 94852K root /system/b2g/b2g 2192 0 1% R 1 1240K 568K root top 96 0 0% S 1 0K 0K root ksmd 2271 1 0% S 1 0K 0K root ksoftirqd/1 402 0 0% S 5 4512K 224K root /sbin/adbd Environmental Variables: Device: Flame 2.0 Build ID: 20140605061016 Gaia: 908f94fda04462001ece86e6b6c15ad8b05f7526 Gecko: 219b3ed1b996 Version: 32.0a1 (2.0) Firmware Version: v10G-2

Getting UX input if moving-apps-in-edit-mode is now fast enough.

Flagging Rob and Jacqueline for homescreen review. Whomever can take it, please do. Thank you!

This bug is technically only about the CPU usage of the homescreen edit mode. The bugs for the responsiveness of the homescreen edit mode are tracked by bug 974381 for the legacy homescreen and bug 1009530 for the new vertical homescreen.

Eli, Gregor flagged UX so, unless Gregor says otherwise, we'll address this bug (as well as the others as needed). :)

Just tried it on today's build from master and scrolling while in edit mode seems responsive on the new home screen. That said, dragging icons to re-arrange them is problematic as it either lags or jumps around instead of following my finger. I'll leave the NI on Jacqueline to confirm that there is an existing bug, or, if not, to raise one.

I agree with Rob that the moving icons in edit mode does seem a lot better. I've spoken with Kevin and the optimization bug for edit mode will include the re-arrange issues that we've noticed well as a few others in terms of performance. Bug 1022713.

For the 50% CPU usage, please check the firmware version. As I understand it, some versions of firmware (RIL issues?) case this 50% CPU usage, and some newer versions do not. Sotaro, do you have more details?

I faced 2 problem in the past. One is caused by nfc it is Bug 1008000. Other is ril. About the ril problem, I fixed it just by updating the base rom.

(In reply to Sotaro Ikeda [:sotaro] from comment #31) > I faced 2 problem in the past. One is caused by nfc it is Bug 1008000. Other > is ril. About the ril problem, I fixed it just by updating the base rom. Nfc problem happened only on v1.4 flame.

Both cases, UnixSocketImpls are created often you can check it by using gdb. http://mxr.mozilla.org/mozilla-central/source/ipc/unixsocket/UnixSocket.cpp#26

This is for the Vertical homescreen right? If so there's also bug 1023940 which is very similar. We landed a will-change which will lower the costs.

It looks like this bug was filed for the current homescreen (which is still shipping on tablets). Because this will not be on phones in 2.0, and I don't think we're blocking on tablets in 2.0, removing the blocking flag.

This is for old homescreen...not shipping old homescreen