Closed Bug 1018592 Opened 10 years ago Closed 10 years ago

Lock screen fade out is again < 60 fps

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::System::Lockscreen
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-b2g:2.0+)

Status:
RESOLVED WORKSFORME
Milestone:
2.0 S6 (18july)
Project Flags:
blocking-b2g 2.0+

People

(Reporter: timdream, Unassigned)

References

Details

(Keywords: perf, regression, Whiteboard: [c=regression p= s= u=2.0] ) 

The lock screen unlock fade out is unfortunately regressed again.

Greg, could you quickly bisect which bug regressed this?
Flags: needinfo?(gweng)
I suspect that is because of the status bar animation (shrink to top) would perform at the same time.
I'll do a bisect to make sure.
Flags: needinfo?(gweng)
blocking-b2g: --- → 2.0?
Keywords: regression, regressionwindow-wanted
Unfortunately, I've bisected it and found that the performance glitch is caused by LockScreen visual refresh...

commit 9b729b38e00bd893cd2f520b7f54e572a10e9c04
Author: John Lu [:mnjul] <jlu@mozilla.com>
Date:   Wed May 21 18:28:15 2014 +0800

    Bug 950884 - [VsD Refresh] Lockscreen Visual Refresh

The good news is, I bisected it at ZTE Open, but Tim said that it would not occur on Flame. So maybe it's not a blocker.
Discussed offline with Greg: the above comment is incorrect and this bug is affecting Open C and Flame. Bug 950884 is NOT the regressed bug either.

We need the regression range on this.

Triage: this should block because this is a regression of our previous hard work bug 945082 bug 937630
blocking-b2g: 2.0? → 2.0+
Well, one correction:

Open C -> Open
Assignee: nobody → gweng
Status: NEW → ASSIGNED
QA Contact: ddixon
Unable to provide Regression Window. 

Also, I found that the issue DOES occur on the earliest and latest 1.4 and 2.0 Flame builds on a Flame device.

The following variables posted here indicate that the issue DOES NOT occur on an Open_C device and Buri. 


Issue DOES occur in latest 2.0 Flame build on a Flame device.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140604064615
Gaia: a38a6a5c6fabc97dd16d5360632b5ac5c7e06241
Gecko: c7fdd7e755cd
Version: 32.0a1 (2.0) MOZ
Firmware Version: v10G-2
  

Issue DOES occur in earliest 2.0 Flame build we have access to on a Flame device.
 
Environmental Variables:
Device: Flame 
Build ID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Version: 31.0a1  MOZ
Firmware Version: v10G-2


Issue DOES NOT occur on latest 2.0 Buri build. 

Environmental Variables:
Device: Buri 2.0
Build ID: 20140603122235
Gaia: dd9e74d196675b0b05170f0ab94a80a36697a551
Gecko: 298b39b50ff7
Version: 32.0a1 (2.0) MOZ
Firmware Version: v1.2device.cfg

DOES NOT occur in earliest 1.4 build we have access to on Open_C device.

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140424123005
Gaia: fc95009476fac9ce205a59b237d146ca7f6f42e7
Gecko: 37237034e45c
Version: 30.0a2 (1.4) MOZ
Firmware Version: P821A10V1.0.0B06_LOG_DL


DOES NOT occur in latest 1.4 build on Open_C device.

Environmental Variables:
Device: Open_C 1.4
Build ID: 20140604043817
Gaia: 229aa1147211b10fe8b27b975fbf02c3a6ec9fa3
Gecko: d8e93180b601
Version: 30.0 (1.4) MOZ
Firmware Version: P821A10V1.0.0B06_LOG_DL

DOES NOT occur in latest 2.0 build on Open_C device.

Environmental Variables:
Device: Open_C 2.0
Build ID: 20140604064615
Gaia: a38a6a5c6fabc97dd16d5360632b5ac5c7e06241
Gecko: c7fdd7e755cd
Version: 32.0a1 (2.0) MOZ
Firmware Version: P821A10V1.0.0B06_LOG_DL
Keywords: regressionwindow-wanted
Target Milestone: --- → 2.0 S5 (4july)
Keywords: perf
OS: Mac OS X → Gonk (Firefox OS)
Priority: -- → P1
Hardware: x86 → ARM
Whiteboard: [c=regression p= s= u=]
Severity: normal → blocker
Whiteboard: [c=regression p= s= u=] → [c=regression p= s= u=2.0]
Depends on: 1028216
Let's investigate this further when bug 1028216 lands.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #7)
> Let's investigate this further when bug 1028216 lands.

The backout of bug 1028216 has landed on mozilla-central. Do you still see the issue ?
Hi Duane, could you check if the issue is still there? Thanks.
Flags: needinfo?(ddixon)
I don't see this issue on Flame anymore. (2.1 nightly update 20140705040205)
Given the fact this bug has similar window as bug 1028216, I intend to dup this bug (or WFM) once QA can confirm this no longer happen on the latest build.
Assignee: gweng → nobody
Keywords: qawanted
As display fades, the screen slightly flickers.

I attempted to record a video of the issue, but the camera cannot detect the screen flickering as the display fades.  

Reproduced on 7/5 nightly build and Central 2.1 build on Flame device. 

Environmental Variables:
Device: Flame Master
Build ID: 20140705160202
Gaia: 93daa354671a698634a3dc661c8c9dcb7d824c31
Gecko: 81691a55e60f
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ddixon) → needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
What STR are you using to test this?
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review-]
Flags: needinfo?(ddixon)
(In reply to Jason Smith [:jsmith] from comment #13)
> What STR are you using to test this?

The STR I've been using: 

1. Go through FTU after flashing build.  
2. At home screen, allow display to fade after 1 minute.  
3. Observe <60 fps display fade.
Flags: needinfo?(ddixon) → needinfo?(jmitchell)
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+][lead-review-] → [QAnalyst-Triage+][lead-review+]
Assignee: nobody → gweng
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
(In reply to Duane Dixon (ddixon) from comment #14)
> (In reply to Jason Smith [:jsmith] from comment #13)
> > What STR are you using to test this?
> 
> The STR I've been using: 
> 
> 1. Go through FTU after flashing build.  
> 2. At home screen, allow display to fade after 1 minute.  
> 3. Observe <60 fps display fade.

This STR is not correct. This bug is about the FPS count of lock screen unlock fade out, not the screen dimming timer.

Please read bug 937630 comment 0 for the correct STR and retest. You can also turn on "Show frames per second" to see if the FPS is around 60fps.
Assignee: gweng → nobody
Flags: needinfo?(ddixon)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Tim, thanks for the clarification.  I activated the "Show frames per second".  There are three bracketed numbers: [000][000][000] in the upper left corner of the display. I'm unsure how to read the output concerning these numbers (what they represent, etc).  Could you help me with that? Thanks!
Flags: needinfo?(timdream)
Duane, please read the first number, that should be the number we are looking at.

https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Developer_settings#Frames_per_second
Flags: needinfo?(timdream)
Resetting status to NEW since it's now unassigned
Status: ASSIGNED → NEW
The FPS numbers have changed quite a bit since 990835 landed. Previously, the FPS number was a rotating window of the past 16 frames, which is very difficult and noisy way to measure FPS. The new measurement should be a bit easier to read, but just reading the FPS numbers with your eye is not a very clear indicator of FPS. It also measures FPS from the previous whole second, which can skew the numbers if the animation takes less than 1 second. This may be why it's considered a regression, whereas the previous way of measuring FPS was probably inaccurate. From comment 10 and 11, this might be a WFM unless we have better ways to reproduce.
STR I used: 
1. Flash to build 20140708163531 on Flame device
2. Activate "Frames per second" in Developer HUD menu
3. Lock the display, slide right to unlock display

Actual Results: Leftmost bracketed number of the "Frames per second" debug output averages "25" when user unlocks the display. (10 repro attempt average)

Video: https://www.youtube.com/watch?v=WW1TOU7y-8Q&edit=v

Environmental Variables:
Device: Flame Master
Build ID: 20140708163531
Gaia: dde24450450514039bad6d8ab4fcb7e5d4d44e03
Gecko: ff4e6d562903
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

The screen seems to make a smooth transition here despite the 25 fps average I found.
Flags: needinfo?(ddixon) → needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?]
Tim, can you review comment 20 - based on the frames and video do you still feel this is a works-for-me?
Flags: needinfo?(jmitchell) → needinfo?(timdream)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
I will call the result as WORKSFORME as well. Thanks, Duane and everyone.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(timdream)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.