922341 - e.me search bar causes homescreen to continuously paint

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Steps to reproduce:

1) Unlock phone.
2) Tap in e.me search bar and wait for keyboard to show
3) Press home button to return to normal homescreen

At this point you can observe elevated cpu in "adb shell top -m 5" and logcat messages such as "D/HwcUtils( 2057): Skip layer".

This profile shows that periodic painting is occurring for some reason:

http://people.mozilla.org/~bgirard/cleopatra/#report=fae249b28f887354536331024c0bb95f76a1fb11

This on a buri with these revs:

  Gecko:  149176:5a49762ee832
  Gaia:   caa78c37ea089a39ee3ebadd2dc2677069ccaaac

This may be related to bug 901964.

Comment 1

[Cristian Rodriguez (:crdlc)]

Ran, could you take a look when you have a chance?

Comment 2

[Ran Ben Aharon [:ranbena] EverythingMe]

Yeah we're on it.

Comment 3

[Ran Ben Aharon [:ranbena] EverythingMe]

Hey Ben,

I did some tests on my Unagi device with stg-pr and latest master.

This are the checks I did.
1. In settings I checked "Flash repaint area" and didn't notice a continuous repaint.
2. Using app manager I profiled my device on master. No cpu spikes. Attached an image to the Bug.
Couldn't do the same for stg-pr for some reason - Homescreen crashed repeatedly.

Right now, master is more advanced than stg-pr in many ways - features and bugs. Could you redo the test on it?

Thanks, Ran

Comment 4

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Master profiling screenshot

Master profiling done on Unagi with App Manager - shows no spikes

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

I'm sorry, I'm not familiar with what stg-pr is.  Can you provide a link?

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Also, did you perform that profile with native stack unwinding enabled?  You probably won't see anything in the profile without that.

To enable you need to do a clobber build with 'export MOZ_PROFILING=1' in your .userconfig.  You also need an update-to-date b2g, so I would recommend doing a ./repo sync.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

I just ran with stg-pr and still see the issue.

Note, painting flashing does not actually occur with this issue.  This kind of makes sense given the "Skip layer" message coming out of logcat.

Here is a profile with stg-pr:

 http://people.mozilla.org/~bgirard/cleopatra/#report=6f6613e9ba6909b4b708aecde56d9ceb89300589

That was using pseudo stacks, so you can probably ignore my comment 6.

Can you upload the profile you ran in the online cleopatra and post the link?  Just hit the share button in the lower left after you open the profile.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Also, all of my testing is on the buri.  I suppose its possible this is a platform specific issue.

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Here is another profile using native stacks and 1000hz sampling:

  http://people.mozilla.org/~bgirard/cleopatra/#report=4251cf9eefeef3e54151ca7b789c7827a1172210

Nothing is jumping out at me, but maybe someone else might see something.

If I had more time to look at this I think I would start hacking out pieces of the code to see if I could isolate what was triggering it.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Ben Kelly [:bkelly] from comment #8)
> Also, all of my testing is on the buri.  I suppose its possible this is a
> platform specific issue.

Well, buri is a target production device, unagi isn't. We should ask the e.me guys to recheck this on Buri.

Anyways - In your opinion, do you think this repainting issue is bad enough to block? What's the performance impact overall if we don't fix this against target partner metrics?

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jason Smith [:jsmith] from comment #10)
> Anyways - In your opinion, do you think this repainting issue is bad enough
> to block? What's the performance impact overall if we don't fix this against
> target partner metrics?

Hmm, well it appears the Homescreen CPU usage only continues while Homescreen is in the foreground.  So I don't think this will impact other apps.  It seems it could have some minor impact on swipe animations, etc.

Combined with bug 901964 I kind of have a gut feeling this is a gecko issue around animations, not a problem with the apps.  I don't have any evidence yet to support that, though.

At this point it doesn't seem to have enough impact to the user to block.

Comment 12

[Ran Ben Aharon [:ranbena] EverythingMe]

Attachment: Patch - redirect to github PR

I noticed on Nightly+Mac+Retina that search results are accompanied by a blinking scrollbar. It had to do with the bottom "load more" progress bar being visibly hidden but still display:block. Small change to the css and it looks to be fixed.

Comment 13

[Ran Ben Aharon [:ranbena] EverythingMe]

Ben, can you test the patch?

Comment 15

[Cristian Rodriguez (:crdlc)]

Comment on attachment 813953 [details]
Patch - redirect to github PR

perfect

Comment 16

[Ran Ben Aharon [:ranbena] EverythingMe]

Landed in master
https://github.com/mozilla-b2g/gaia/commit/533c53b790f7d538c50d3e3cb5493ab2901f0148

Comment 17

[Ben Kelly [:bkelly, not reviewing]]

Confirmed that I can no longer reproduce the symptoms I saw previously.

Awesome work guys, thanks!