+++ This bug was initially created as a clone of Bug #1016559 +++ Transition between lockscreen & home has a slight delay. The scenario is a User is on the lock screen and slides to the right to unlock. This needs to be much smoother. A partner pointed this information too. Responsive guidelines are listed at https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines The guidelines that are applicable here: 1) Perception of cause and effect: (140 ms): Touch states should occur within 140 ms of being touched 2) Hand Eye coordination (100 ms): Sliding to the right should generate a visual response within 100ms when initiating a slide. 3) Perception of Progress: (1 sec): As a user I expect to be able to interact with the home screen app within 1 sec.

I suspect part of problem (low framerate during the *middle* of the animation) is caused by bug 1037220. Try the patch posted in the bug and/or remove the opacity fade. We have to use an intermediate buffer to render the fade effect with multiple child layers and we currently do so in a very bandwidth unfriendly method but bug 1037220 should fix this soon on master. I suspect we also have problems with style flushes during the start/end of the animation. This was the case last time I looked but it would be worth double checking with a profile.

I believe we also see this delay when unlocking the device when not having a lockscreen. Perhaps that should be another bug though?

Wilfred, Ravi or Candice, Is this targeted for 2.1? Are there flags or blocking relationships that need to be set on this to indicate that? Thanks, Mike

Unlocking device is a high occurrence interaction for users, so this adds a lot of immediate value. So we should target 2.1. I don't think it has been promised to partners for any particular release. If Engg can do it for 2.1, then we can flag 2.1 as target release for this bug.

(In reply to Mike Lee [:mlee] from comment #4) > Wilfred, Ravi or Candice, > > Is this targeted for 2.1? Are there flags or blocking relationships that > need to be set on this to indicate that? > > Thanks, > Mike Per Ravi's comment, Mike will your team be able to commit this in 2.1?

Bug 1037220 landed, I expect we just need to make sure we're building our layers properly.

Benoit, I tried the latest build 20140801000201 on Flame device. The unlock 'seemed' quick. Though it was not very smooth (my comparison was with IPhone). 1)Do you think there are possibilities of smoothening and uniform frame transitions to home screen. Can we capture profile to know where it is not smooth. 2)You commented that "we just need to make sure we're building our layers properly", who can do that? Quantitative Goals: For the goals, we have stated the following UX quantitive goals 1) Perception of cause and effect: (140 ms): Touch states should occur within 140 ms of being touched 2) Hand Eye coordination (100 ms): Sliding to the right should generate a visual response within 100ms when initiating a slide. (this goal is currently difficult as apparently hw takes 125 msec from touch to our sw) 3) Perception of Progress: (1 sec): As a user I expect to be able to interact with the home screen app within 1 sec. For this micro-interaction of unlocking device, we also need 'Uniformity of frames'. (i.e. no Jank). eg: As a User, when I move a finger across the screen to unlock, frame displacement should be smooth to transition to home screen, so I have a consistent visual user experience. The Std deviation of the frame displacement should <= 5 pixels (for example). Qualitative: Since the tools for quantitative measurements are not yet available, we may have to examine this visually and determine when it is good enough. +Geo to comment from QA perspective and how to confirm it is fixed. Wilfred, Can you request customers to try out the latest builds, and get their feedback.

Just so that we're not confused - this is sort of a meta bug, not part of 2.0 or 2.1, but an ongoing background item for making things faster. I'm not sure how much of a value there is in this bug existing, as it contains way too much at this point. We may be better off separating things into different requests, especially when we start talking about incorporating project silk into this.

(In reply to rdandu from comment #8) > Benoit, I tried the latest build 20140801000201 on Flame device. The unlock > 'seemed' quick. Though it was not very smooth (my comparison was with > IPhone). > 1)Do you think there are possibilities of smoothening and uniform frame > transitions to home screen. Can we capture profile to know where it is not > smooth. Yes it's possible. > 2)You commented that "we just need to make sure we're building our layers > properly", who can do that? > It should be up app owners: https://wiki.mozilla.org/Modules/FirefoxOS#System > > Qualitative: Since the tools for quantitative measurements are not yet > available, we may have to examine this visually and determine when it is > good enough. ./profile.sh already provides all the tool needed to analyze latency and animation smoothness. (In reply to Milan Sreckovic [:milan] from comment #9) > especially when we start talking about incorporating > project silk into this. The homescreen unlock runs at 30 FPS on my flame-master build. We're so far from 60 FPS that I don't think project silk comes into play until we get in the 55 FPS+ range.

need info'ing Alive, who's listed as System app owner. Alive, For the System App (lock screen, and transition to homescreen), can you comment on making sure we're building our layers properly.

Re: verification, I'd go off qualitative (i.e. human) evaluation primarily. The three factors I understand here, given no video, are delay before the slide occurs, whether the slide tracks finger, and the uniformity of the animation. Those should verify as "nearly imperceptible," "yes," and "visibly smooth" respectively. The micromeasurement thresholds listed are appropriate, and as Benoit says, we can pull uniformity from existing tools. However, I view them more as ways to quantify, lock in, and improve existing already-desirable behavior than as independent goals--particularly until we have automated measurement in place. For now, I'd largely go off human evaluation. Once it's apparently smooth, I'd turn to micromeasurements.

The information provided here is vague, and bug 1037220 is a gecko bug, why do we need to "fix" it in gaia? What is "build layer properly"? Anyway I am defer-ing the request to Tim/Greg to see if they know what's next.

Yes, that's my question, too... if you mean graphic layer, Gaia can do nothing except re-arrange DOMs, but this has been discussed once, according to Jerry's opinion, and we found it would be too tricky to reduce child DOMs or merge them into one giant DOM. So, before we can do anything, at least we need to know what Gaia can do in a proper way.

To get an efficient lockscreen we need to make sure that the following happens during the animation: - The Lockscreen is broken down into the optimal representation. Something like: * One layer for the lockscreen, one layer for the content we unlock to. - That the fade out is implemented using a CSS transition on opacity. * This animation must hit the off-main-thread-animation path. If you're not familiar with layers and off main thread animation this page applies to Gecko as well: http://www.html5rocks.com/en/tutorials/speed/layers/ https://bugzilla.mozilla.org/show_bug.cgi?id=1038500 http://www.phpied.com/css-animations-off-the-ui-thread/

OMTA has been tried once and we're sure LockScreen use only transition and opacity to do the fade out, so 2. is satisfied. About 1: from LockScreen side, what we can do is to check if it composited into one layer with help from graphic team, and the 'content we unlock to' needs more check because we may unlock to Homescreen, or other apps. By the way, LockScreen would become an app in near future. And as I tried, to make it as an app seem bring some different performance impact, so in the future we may face a general issue to make app animation become smoother, rather to treat LockScreen as a special case.

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #16) > OMTA has been tried once and we're sure LockScreen use only transition and > opacity to do the fade out, so 2. is satisfied. Yes but are you sure it's hitting the OMTA path. There's many more requirements than that. Looking at the FPS/Transaction shows the number in sync which indicates that OMTA path is not being hit. How are you so sure? > > About 1: from LockScreen side, what we can do is to check if it composited > into one layer with help from graphic team, and the 'content we unlock to' > needs more check because we may unlock to Homescreen, or other apps. > > By the way, LockScreen would become an app in near future. And as I tried, > to make it as an app seem bring some different performance impact, so in the > future we may face a general issue to make app animation become smoother, > rather to treat LockScreen as a special case. Unless the plan is to that do on the current train I don't think this should impact the resolution of this bug. We first have to get the lockscreen to perform well in this simpler case if we want it to perform better when it's been separated into a new process.

> There's many more requirements than that... From Gaia side, what I'm sure is we use only transform:size and opacity to do the animation, and this, according to other graphic team members I've discussed with, satisfy the requirements to trigger OMTA in general. If this is not enough, either the information I've got is incorrect, either there is some bugs caused to trigger OMTA would fail even though the front-end code has been designed to do that. And according to the code to check if we can perform OMTA/OMTC, the 'CanPerformOnCompositorThread' function, which is mainly rely on ''

'CanAnimatePropertyOnCompositor', which would check IsGeometricProperty() frame->Preserves3D() && frame->Preserves3DChildren() IsSVGTransformed() and property allowed: transform && opacity in the code. Since LockScreen use no 3D, SVG, geometric properties changes to do the animation, what would cause OMTA/OMTC unsatisfied under these conditions?

I don't have a full list. The best way is to run this through the debugger. You can also inspect code that calls IsAnimationLoggingEnabled and turn on the logging but the debugger is the best tool. I don't know who you talked to or what they said. What I do know is there's more requirement for OMTA then just what was mentioned above.

Well, as you said, what I can do is NI (maybe offline) other graphic guys to debug it and to see if there is any issue with OMTA/OMTC. I'm not expert to debug with Gecko GFX, and what I've posted is what I have now, so this is necessary.

To prevent any misunderstanding: offline is because we may need some discussions and tests before we can post anything on Bugzilla. We would of course report the result after that.

(In reply to Greg Weng [:snowmantw][:gweng][:λ] from comment #21) > Well, as you said, what I can do is NI (maybe offline) other graphic guys to > debug it and to see if there is any issue with OMTA/OMTC. I'm not expert to > debug with Gecko GFX, and what I've posted is what I have now, so this is > necessary. There is currently no indication that this is a platform bug in OMTA. We know that OMTA works when all the requirements are satisfied. Maybe you found a bug in platform, maybe not. A reduced test case that clearly shows that all the criteria for OMTA are satisfied, but the fast code path is still not hit would be the way to proceed. This is on Gaia, until proven otherwise - not on platform until proven otherwise.

On Gaia, but for what? BenWa said he suspect that there is no OMTA for the unlocking animation, and suggested me to investigate with that. If so, what I can do is what I mentioned, to get help from others, since it, from Gaia side, seems satisfied the OMTA requirement to trigger it. Otherwise, if it's not a GFX related performance issue, what I can do is to reduce DOM elements on LockScreen overlay, or to test it with the background app with blank page. Although these tests have been tried once, and they're not helpful, according to the previous results.

IMHO there is just too little information available for Gaia developers to work on this bug efficiently. We have seem the exactly same bug being filed 3 times and not only it's hard to tell what Gaia could do to fix it but also tracks platform changes on graphics. It also make more sense if what we have spend time on can be protected by tests. We really can't afford going through this bug in every release.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #25) > IMHO there is just too little information available for Gaia developers to > work on this bug efficiently. What information is missing? No one has tried what I suggest in Comment 20 or minizing the testcase until OMTA work.

After talking to Peter offline, he will check comment 20 first. That said, I don't see any visible regression on 2.1 since bug 1018592 was closed as WFM. Maybe it never reaches OMTA at first place.

(In reply to Kevin Grandon :kgrandon from comment #3) > I believe we also see this delay when unlocking the device when not having a > lockscreen. Perhaps that should be another bug though? Kevin, the original bug was always about lock screen fade out animation. If you are talking about the time it takes for screen to turn on, that's another bug and I've filed under bug 1052338.

(In reply to Benoit Girard (:BenWa) from comment #20) > I don't have a full list. The best way is to run this through the debugger. > You can also inspect code that calls IsAnimationLoggingEnabled and turn on > the logging but the debugger is the best tool. I just enabled 'log slow animation' from developer option and make sure log is enabled from gdb. But I didn't see any performance log for it. > > I don't know who you talked to or what they said. What I do know is there's > more requirement for OMTA then just what was mentioned above. About the lockscreen animation, I think it already hit the OMTA path[1][2] from below logs. Now I have another question, how do we measure the animation performance? From below log, the animation transaction is about 320ms (901-581). 08-12 05:29:25.581 7217 7254 I Gecko : pchang SampleAnimations matrix 1.069536 1.069536 08-12 05:29:25.581 7217 7254 I Gecko : pchang SampleAnimations opacity 0.930464 08-12 05:29:25.581 7217 7254 I Gecko : pchang SampleAnimations matrix 1.000000 1.000000 08-12 05:29:25.611 7217 7254 I Gecko : pchang SampleAnimations matrix 1.106478 1.106478 08-12 05:29:25.871 7217 7254 I Gecko : pchang SampleAnimations matrix 1.557616 1.557616 08-12 05:29:25.871 7217 7254 I Gecko : pchang SampleAnimations opacity 0.442385 08-12 05:29:25.901 7217 7254 I Gecko : pchang SampleAnimations matrix 1.584795 1.584795 08-12 05:29:25.901 7217 7254 I Gecko : pchang SampleAnimations opacity 0.415205 [1]http://dxr.mozilla.org/mozilla-central/source/gfx/layers/composite/AsyncCompositionManager.cpp#482 [2]http://dxr.mozilla.org/mozilla-central/source/gfx/layers/composite/AsyncCompositionManager.cpp#489

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #28) > Kevin, the original bug was always about lock screen fade out animation. If > you are talking about the time it takes for screen to turn on, that's > another bug and I've filed under bug 1052338. Maybe that's what I'm thinking about then. Thanks.

Given the fade out transition reaches OMTA (comment 29) and comment 30, I am not entirely sure what specifically we want to fix in the bug. Kevin, could you be more specific on why you cloned this bug from bug 1018592? Maybe we should tackle these issues independently.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #31) > Kevin, could you be more specific on why you cloned this bug from bug > 1018592? Maybe we should tackle these issues independently. If performance here is good enough, we can close it. I only cloned it because that one was marked as confidential and this was something I was interested in working on this in public if we can.

Let's work on bugs with more specific descriptions.

This bug is not resolved Tested on a Flame running nightly build with build identifier 2140816160201 I’ve tested slide unlock and pass code lock. For both I see a noticeable lag between the end of user operation and transition start. This is not the smoothness customers expect from a premium brand. Please improve

(In reply to Olof Wickström from comment #34) > This bug is not resolved > Tested on a Flame running nightly build with build identifier 2140816160201 > I’ve tested slide unlock and pass code lock. For both I see a noticeable lag > between the end of user operation and transition start. > > This is not the smoothness customers expect from a premium brand. > > Please improve Can we please use another, more descriptive bug? Your comment is very descriptive compare to comment 0 and it's certainly we can work on, compare to comment 0.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #35) > Can we please use another, more descriptive bug? Your comment is very > descriptive compare to comment 0 and it's certainly we can work on, compare > to comment 0. I've filed bug 1054904.

Looks good. Thanks, Tim.

Why is this reopened and marked to feature-b2g: 2.1 without any comments?

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #38) > Why is this reopened and marked to feature-b2g: 2.1 without any comments? agree with Tim. please provide more details of reproducibility, areas of slowness, etc.. so this bug can be actionable. Especially if we're requesting as a feature blocker.

One problem is we had fired another bug for the actual lag at Bug 1054904, so this reopening may be unnecessary. And even before that, Comment 32 and Comment 33 left the conclusion that we should have a better bug with better description. However, it looks like these two reopenings were done without mentioning the comments, at least from the follow-up comments there are no descriptions of the motivation.

It seems like we want this to be open for tracking purposes - if so, we can reopen and turn this into a [meta] bug tracking general lockscreen perfrormance issues. I'm not sure if there's value in doing so, but it's an option.