The lock screen unlock fade out is unfortunately regressed again. Greg, could you quickly bisect which bug regressed this?

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.

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

Well, one correction: Open C -> Open

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

I guess it should be fixed by bug 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.

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.

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

What STR are you using to test this?

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

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

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!

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

Resetting status to NEW since it's now unassigned

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.

Tim, can you review comment 20 - based on the frames and video do you still feel this is a works-for-me?

I will call the result as WORKSFORME as well. Thanks, Duane and everyone.