Closed Bug 823418 Opened 12 years ago Closed 11 years ago

[Lockscreen] Takes too long to awake the lock screen

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86_64
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:-)

Status:
RESOLVED INVALID
Project Flags:
blocking-basecamp -

People

(Reporter: johnshih.bugs, Unassigned)

References

Details

(Keywords: perf)

Attachments

(1 file)

logcat output after pressing the power button
54.83 KB, text/plain
Details 
## Environment :
Unagi phone, build 2012-12-20
Build info: 
gaia master : 7304395ff0cdfe4de6eb4dd8efc53e89ddca1ed2
mozilla-b2g18 : 81b03770cbbc

## Repro :
1. Reboot the phone
2. Lock screen shows up, unlock the phone
3. Press power button to sleep the phone
4. Press power button again to awake the phone

## Expected:
* The lockscreen will show up as soon as I press the power button

## Actual:
* It took about 7 second to show the lock screen

## Note:
* The steps are not always reproducible, should try more times
blocking-basecamp: --- → ?
Maybe related to bug 796248
Assignee: nobody → yurenju
Doesn't look like a Gaia issue to me. Thinker, what's the proper way to investigate this?
Flags: needinfo?(tlee)
I am pretty sure this is a Gecko issue.

This only happens to phones with the new straight line design of the lock screen, and that design doesn't redraw the screen (with a "bounce" animation) as soon as the lock screen is shown.

Gaia does paint the screen black when the screen is turn off (by adding a "screenoff" class to the system app [1]), but the class will be removed as soon as the screen is turned back on [2]. For some reason Gecko doesn't repaint the screen when [2] happens.

Alternatively, we should just remove the "screenoff" code if that doesn't cause any flashing of old content.
Assignee: yurenju → nobody
Component: Gaia::System::Lockscreen → General
QA Contact: atsai
I can't not reproduce with the build in 12/25
gaia master: 1be7bf421a6498f6e73377e3028227dea99b3431
b2g-18: e261861b0270
(In reply to John Shih from comment #5)
> I can't not reproduce with the build in 12/25

Thanks, bb-.
blocking-basecamp: ? → -
Flags: needinfo?(tlee)
Myself and a few other engineers are noticing this - and it is extremely jarring to press the power button, and not have the screen immediately show. It's intermittent, but I would highly recommend blocking on this. I can demo if needed.
blocking-basecamp: - → ?
I am seeing this on the 1/7 nightly build.
Is it also true if lockscreen was disabled?
It seems the same issue as bug 796248.
Blocks: 796248
I only see this when the lockscreen is enabled.
It does appear to be some paint issue - as the screen will respond to touch events. It takes a long time for it to appear, but a touch on the screen will make it appear immediately.
Is this a regression?
Keywords: qawanted, regressionwindow-wanted
I also met this on my own build today

2013-01-08
gaia master: df13e23c775d02f430e01799ea8b19d61afb4b86
b2g-18: 9220d6eb3f77

and I think there was a period that this bug can't reproduce (at least on 12/27 ~ 1/4)
actually it's very easy to reproduce when it is reproducible
This might be a layout and/or display list invalidation bug more than an actual gfx bug if touching the screen makes it appear right away.
Also, if you have the FPS counter enabled, you can see fps numbers being printed way before the gaia UI is drawn the first time.  So the compositor is actively drawing to the framebuffer.
No idea if it's meaningful, but watching logcat I consistently see

D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:81920 offset:1228800 fd:124
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:8192 offset:1310720 fd:129
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:8192 offset:1318912 fd:134
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:81920 offset:1327104 fd:139
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:8192 offset:1409024 fd:144
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:8192 offset:1417216 fd:149

when the lockscreen instantly appears, and

D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:163840 offset:1228800 fd:124
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:16384 offset:1392640 fd:129
D/memalloc(  108): /dev/pmem: Allocated buffer base:0x4a100000 size:16384 offset:1409024 fd:134

when the delay occurs.
Actually, I may be wrong about the first part, but I have never seen a delayed lockscreen without the second memalloc lines.
Comments 19 and 20 are probably red herrings. It looks like those buffers are the ones for the lockscreen bounce animation. I have determined that I can only reproduce this after I unlock the phone for the first time. If I just keep turning the screen on and off, I cannot reproduce the pauses.
However, it sure looks like the screen doesn't update until the lock bounce animation actually begins.
jst suggested we may want to work around this in Gaia if possible.
Assignee: nobody → josh
blocking-basecamp: ? → +
The very simplest Gaia workaround I can think of would be to initiate the bounce animation as soon as the screen powers one. Vlad's theory that a swapBuffer call fails hasn't seemed to pan out in my investigations.
blocking-basecamp: + → ?
I have been unable to reproduce the problem after setting ELASTIC_INTERVAL to 0 in lockscreen.js. This also leads to some temporary animation weirdness if the animation is already in progress when the screen turns on, so a slightly more complex workaround might be required if that's deemed unacceptable.
I'll work on finding a regression range for this tomorrow morning.
QA Contact: gmealer
(In reply to Josh Matthews [:jdm] from comment #25)
> I have been unable to reproduce the problem after setting ELASTIC_INTERVAL
> to 0 in lockscreen.js. This also leads to some temporary animation weirdness
> if the animation is already in progress when the screen turns on, so a
> slightly more complex workaround might be required if that's deemed
> unacceptable.

The author of the lockscreen is going to help in order to do a workaround in Gaia. Assigning back to Yuren then.
Assignee: josh → yurenju
I don't think this bug blocks again if we can workaround it in Gaia for v1. Let's renominate it to reflect that.
blocking-basecamp: + → ?
Set the assignee back.
Assignee: yurenju → nobody
... for real.
Assignee: nobody → josh
Blocking-, this will be worked around in gaia.
blocking-basecamp: ? → -
I'm having problems reproducing this on a relatively current build (1/7)--haven't seen the behavior at all on that build or the 1/9 build. 

Also, the current set of steps is onerous to do a regression range with, because of the necessity of repeatedly rebooting the phone within any given build, then the need to reflash the phone between builds. 

The problem being intermittent also makes getting a range very expensive because an absence of symptoms doesn't necessarily indicate being out of the range.

So, a couple of things before I go further with this:

1) John, can you verify that the STR are the absolute minimum? Do I absolutely have to reboot for each try, and do I have to click through lock screen?

2) Is there any possible way to get a more reproducible set? You say "very reproducible" but I'm unsure if you mean very frequent but intermittent or what.

3) Is the range a nice-to-have or must-have request? If it's the former, IMO this isn't a good candidate for getting a range on because of the reasons mentioning above. If it's necessary, I estimate it'll take several hours to get a reliable range, assuming we can.
One thing to note - I have had trouble reproducing it on one phone, and theorize that the lack of a SIM card might be enough to cause the screen to update and hide the problem. I don't know whether rebooting is necessary, but clicking through the lockscreen definitely is. Regardless, given that this bug is no longer blocking, I don't think a regression range is a requirement at this point.
OK. I'm going to pull the regressionwindow-wanted and qawanted keywords, then, but will keep my name on as contact. I'll continue to keep an eye out for the problem as well.

If you change your mind, or there's something else I can help with, put qawanted back on and it'll show up on my radar.
Keywords: qawanted, regressionwindow-wanted
Looks like this bug has gone quiet, but I am seeing this today on hamachi with:
- gecko: m-c:729c5f06584a
- gaia: master:0fdc90c480de83e3acf57b734f0797751c900a28

When I press the power button, I see the display's backlight turn on, but the lockscreen doesn't appear for another 7 seconds, exactly as in comment 0. It's really annoying--at first I thought the build was broken.
blocking-b2g: --- → 1.3?
I'm seeing this on a non-DEBUG build, and the 7-second delay is 100% reproducible.
Assignee: josh → nobody
And still present in:
- gecko: m-c:5417e5da2ceb w/
- gaia: master:0fdc90c480de83e3acf57b734f0797751c900a28
Keywords: perf
Component: General → Gaia::System::Lockscreen
AFAIK this is not a gaia issue.
Component: Gaia::System::Lockscreen → General
Mike

Are we saying this issue is on the Gecko?

What is the reproducibility rate?

What device did we verify it on?
Flags: needinfo?(mhabicher)
I can't remember the last time I saw this problem. John?
Flags: needinfo?(mhabicher) → needinfo?(jshih)
I'm not sure if we solved the root cause of this issue, but it seems no long reproducible.
I'll have someone to have double check.
Thanks
Flags: needinfo?(jshih)
I can't reproduce this anymore. What is the status of this bug? Should we close this as resolved invalid?
(In reply to Walter Chen[:ypwalter][:wachen] from comment #42)
> I can't reproduce this anymore. What is the status of this bug? Should we
> close this as resolved invalid?

Yeah. It's probably no longer applicable.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: