Hide statusbar below fullscreen app

RESOLVED FIXED

Status

Firefox OS
Gaia::System
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: diego, Assigned: alive)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+, b2g18 fixed)

Details

(Whiteboard: [cr 473351])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Each time the system clock seconds hit :00 the CPU user load spikes ~25%. The activity all comes from the main b2g process.

This forces new frames to be rendered, regardless of actual content updates. For example, even when there's a static fullscreen app hiding the status bar.

The spike is noticeable enough to skew power performance measurements.
(Reporter)

Comment 1

5 years ago
My guess is the status bar's visible rect is not being properly hidden for fullscreen apps.

Also, there may be some unavoidable alarm checking in the background.
tracking-b2g18: --- → ?
(Can we take this public since there aren't specific numbers here?)
Component: General → Gaia::System
(Reporter)

Updated

5 years ago
Group: qualcomm-confidential
tracking-b2g18: ? → +
Assignee: nobody → alive
Created attachment 717759 [details]
https://github.com/mozilla-b2g/gaia/pull/8290

Patch proposal:

Utilize custom events and mozfullscreenchange to change the visible state of statusbar.
Attachment #717759 - Flags: review?(timdream)
Statusbar unit test is disabled now. I would take a look to bug 840500 to bring it back if possible.
Comment on attachment 717759 [details]
https://github.com/mozilla-b2g/gaia/pull/8290

Is it possible to use CSS only approach?

Also, can we make sure that status bar is the source of the CPU spike first, and hide it does fix the issue?

r+, if the answer is yes to both questions.
Attachment #717759 - Flags: review?(timdream) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #5)
> Comment on attachment 717759 [details]
> https://github.com/mozilla-b2g/gaia/pull/8290
> 
> Is it possible to use CSS only approach?

IMO no, too tricky to make the transition begins/ends at the same time app is opened/closed. I wonder race condition may happen.

> 
> Also, can we make sure that status bar is the source of the CPU spike first,
> and hide it does fix the issue?

I recommend to let the reporter/QA to verify this.

> 
> r+, if the answer is yes to both questions.
(In reply to Diego Wilson [:diego] from comment #0)
> Each time the system clock seconds hit :00 the CPU user load spikes ~25%.
> The activity all comes from the main b2g process.
> 
> This forces new frames to be rendered, regardless of actual content updates.
> For example, even when there's a static fullscreen app hiding the status bar.
> 
> The spike is noticeable enough to skew power performance measurements.

Diego, could you please test the patch attached to see if this solves the problem? I don't know how to test it. Thanks. Or you could provide the way to test.
(Reporter)

Comment 8

5 years ago
@alive

I still see the spike even with the gaia patch.

This is how I measure:

1. Set display setting to "always on"
2. Open Gallery
3. Monitor CPU usage with |adb shell top | grep User|
4. In another terminal monitor system time with |while :; do adb shell date; sleep 1; done|

You'll see the spike every time the seconds hit :00
Hi,

Does this only happens when gallery is foreground? How about other app?

(In reply to Diego Wilson [:diego] from comment #8)
> @alive
> 
> I still see the spike even with the gaia patch.
> 
> This is how I measure:
> 
> 1. Set display setting to "always on"
> 2. Open Gallery
> 3. Monitor CPU usage with |adb shell top | grep User|
> 4. In another terminal monitor system time with |while :; do adb shell date;
> sleep 1; done|
> 
> You'll see the spike every time the seconds hit :00
(Reporter)

Comment 10

5 years ago
This happens all the time, regardless of the app
Looks like the patch here has already landed on gaia master.  Setting leo+ as this has been reported again during our v1.1 test, and flags to request uplift to v1.1
Blocks: 856773
blocking-b2g: --- → leo+
status-b2g18: --- → affected
tracking-b2g18: + → ---
Flags: needinfo?(jhford)
Whiteboard: [cr 473351]
(Reporter)

Comment 12

5 years ago
FWIW I don't see this fixed on master either
Diego, if the patch doesn't fix the problem to you,
then https://bugzilla.mozilla.org/show_bug.cgi?id=834765#c1 may not be root cause.
But the fix here is just to fix what you addressed in comment 1.
If you could give more info then we could move forward. Otherwise it's difficult for us to "guess" the reason of CPU spike, and, furthermore, we don't know how to estimate it. I even wonder the root cause is in gecko or gaia.

However, I suggest to track it in a new (blocking) bug.
(Reporter)

Comment 14

5 years ago
@alive

Yes, it does seem like the root cause of the spike is unrelated to screen draws

@m1

Do you agree with spinning off a new bug for this?
WFM
(Reporter)

Comment 16

5 years ago
Created bug 864516 and retitled this bug to reflect the attached patch
Summary: CPU load spike at each minute mark of system time → Hide statusbar below fullscreen app
Let's close this one because the patch is landed.
master: https://github.com/mozilla-b2g/gaia/commit/9d3cf27b276fdce42ca1b73550dabb01d1732c69
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Uplifted 9d3cf27b276fdce42ca1b73550dabb01d1732c69 to:
v1-train: 916baadb39c6e16e0602f811a662c0fccb6d4b91
status-b2g18: affected → fixed
Flags: needinfo?(jhford)

Updated

5 years ago
See Also: → bug 873931

Comment 19

5 years ago
This patch caused an regression, Bug 873931.
You need to log in before you can comment on or make changes to this bug.