e.me search bar causes homescreen to continuously paint



Firefox OS
4 years ago
4 years ago


(Reporter: bkelly, Assigned: ranbena)


({perf, regression})

Firefox Tracking Flags

(Not tracked)



(2 attachments)



4 years ago
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:


This on a buri with these revs:

  Gecko:  149176:5a49762ee832
  Gaia:   caa78c37ea089a39ee3ebadd2dc2677069ccaaac

This may be related to bug 901964.


4 years ago
Component: Gaia::Homescreen → Gaia::Everything.me


4 years ago
Blocks: 910302


4 years ago
Keywords: regression
Ran, could you take a look when you have a chance?
Yeah we're on it.
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
Created attachment 813119 [details]
Master profiling screenshot

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


4 years ago
Flags: needinfo?(bkelly)

Comment 5

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

Comment 6

4 years ago
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.
Flags: needinfo?(bkelly)

Comment 7

4 years ago
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:


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

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

Comment 9

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


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.
(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

4 years ago
(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.
Created attachment 813953 [details]
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.
Attachment #813953 - Flags: review?(crdlc)
Attachment #813953 - Flags: review?(amirn)


4 years ago
Assignee: nobody → ran
Ben, can you test the patch?
Flags: needinfo?(bkelly)
Duplicate of this bug: 923640
Comment on attachment 813953 [details]
Patch - redirect to github PR

Attachment #813953 - Flags: review?(crdlc) → review+


4 years ago
Attachment #813953 - Flags: review?(amirn) → review+
Landed in master
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 17

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

Awesome work guys, thanks!
Flags: needinfo?(bkelly)
You need to log in before you can comment on or make changes to this bug.