Closed Bug 1073388 Opened 5 years ago Closed 4 years ago

slide to unlock screen,the time it costs from the hands away from the screen to screen initial complete is 0.7s

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect, major)

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jingmei.zhang, Unassigned)

References

Details

Attachments

(1 file)

[Blocking Requested - why for this release]:

steps to test:
1.Use the default unlock
2.slide the unlock icon to the unlocked position
3.calculate the time between the hands leave away from the screen to screen initial complete
the whole time costs in step3 is about 0.7s.
when compare with the android dolphin, its only 0.19s.
and we want to improve it. 

Through the code and debug, I find that the main time consuming of this process is 

691       app.tryWaitForFullRepaint(nextPaint);   

in this function will call 

  setTimeout(callback);  // the callback is nextPaint

and the between setTimeout function and the execute nextPaint is about 0.3s.

also I find that if we want to unlock the lock screen, we just need move the 

this.overlay.classList.add('unlocked');

before the nextPaint function. and though the test, I have not find the modify has any defect, and the timeconsuming is about 0.2s shorter. 

please give my patch a review, thanks very much.
Attachment #8495813 - Flags: review?(21)
Please just don't nominate issue to 1.4 blocker. I will try to find someone to review your patch
blocking-b2g: 1.4? → ---
Comment on attachment 8495813 [details] [diff] [review]
improve_lockscreen_unlock_speed.patch

Review of attachment 8495813 [details] [diff] [review]:
-----------------------------------------------------------------

::: apps/system/js/lockscreen.js
@@ +670,4 @@
>      }
>  
>      this.overlay.classList.toggle('no-transition', instant);
> +    this.overlay.classList.add('unlocked');

The main reason for this class to be set into the nextPaint callback is to ensure the lockscreen does not transition over an empty homescreen (because its rendering has been discarded by an iframe.setVisible call).

It can happens for any apps that is below the lockscreen.

One possible solution could be to declare the current displayed app below the lockscreen as a visible app in the window manager or to keep the app rendering in memory.

What do you think ?
Attachment #8495813 - Flags: review?(21) → review-
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.