815629 - Lock screen is unresponsive during an incoming call

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect, P2)

Description

[Mike Conley (:mconley) (:⚙️)]

Attachment: ADB log

When calling my dogfood phone, it lights up and rings, but just displays the lock screen instead of the "incoming call" screen.

The lock screen is completely unresponsive, so I can't answer the call.

I've attached the adb log.

Comment 1

[Aaron Train [:aaronmt]]

I received a telemarking call at work on my B2G phone and tried to dismiss the ringing and could not dismiss the call as the lock-screen was completely unresponsive during this time. That was rather annoying.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

I notice that while my dogfooding phone is ringing, the whole UI is really, really laggy and unresponsive. Seems to be doing a ton of thinking.

Once the call starts, everything seems to be OK again.

Comment 3

[Alex Keybl [:akeybl]]

Pulling into C2 since we've gotten many dupes of this issue in feedback.

Comment 4

[Dietrich Ayala (:dietrich)]

Yuren, can you investigate?

Comment 7

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

I extract lockscreen for dialer to an individual app, you can visit below link to install it:
http://yurenju.github.com/swiper/wrapper.html

and FPS about 15~20FPS, it isn't good but better than put it together in dialer app (only about 1 fps). so the root cause is we need to lots of CPU resource for handling incoming call and the performance isn't acceptable with SVG animation.

So I propose two solutions:
1. revert to original swiper design
2. keep new visual design but remove SVG animation and stop on last screen (you can click button to pickup or hangup).

Josh, do you have any idea about this?

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Yuren Ju [:yurenju] from comment #7)
> I extract lockscreen for dialer to an individual app, you can visit below
> link to install it:
> http://yurenju.github.com/swiper/wrapper.html
> 
> and FPS about 15~20FPS, it isn't good but better than put it together in
> dialer app (only about 1 fps). so the root cause is we need to lots of CPU
> resource for handling incoming call and the performance isn't acceptable
> with SVG animation.
> 
> So I propose two solutions:
> 1. revert to original swiper design
> 2. keep new visual design but remove SVG animation and stop on last screen
> (you can click button to pickup or hangup).
> 
> Josh, do you have any idea about this?

Why do we need an animation at all? It makes the screen slower when it is shown (since there are 2 animations in parallels) and make it stressful to answer since you're afraid of missing the call. 

What about having simply 2 buttons on each side, like when the phone is not locked? This will be pretty cheap and quick to do since it will be only code removals!

Comment 9

[Josh Carpenter [:jcarpenter]]

(In reply to Vivien Nicolas (:vingtetun) from comment #8)
> (In reply to Yuren Ju [:yurenju] from comment #7)
> > I extract lockscreen for dialer to an individual app, you can visit below
> > link to install it:
> > http://yurenju.github.com/swiper/wrapper.html
> > 
> > and FPS about 15~20FPS, it isn't good but better than put it together in
> > dialer app (only about 1 fps). so the root cause is we need to lots of CPU
> > resource for handling incoming call and the performance isn't acceptable
> > with SVG animation.
> > 
> > So I propose two solutions:
> > 1. revert to original swiper design
> > 2. keep new visual design but remove SVG animation and stop on last screen
> > (you can click button to pickup or hangup).
> > 
> > Josh, do you have any idea about this?
> 
> Why do we need an animation at all? It makes the screen slower when it is
> shown (since there are 2 animations in parallels) and make it stressful to
> answer since you're afraid of missing the call. 
> 
> What about having simply 2 buttons on each side, like when the phone is not
> locked? This will be pretty cheap and quick to do since it will be only code
> removals!

The slide action is important. It acts like a gun safety: preventing accidental inputs. If we remove it and have only buttons, the user could easily press either Answer or Ignore while taking their phone out of a pocket, bag, etc. So we would strongly prefer to implement a solution that involves a swipe.

> > So I propose two solutions:
> > 1. revert to original swiper design

Not an option, for various reasons.

cc'ing Steve here, since this also involves visual design. We need to retain the interaction design, but modify the visual to be performant.

Comment 10

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

after traced with Thinker, we found it might be a bug on gecko nightly. please see below video, left is firefox stable (17), right is firefox nightly

https://www.dropbox.com/s/513tzzqhw2kz4qv/repaint.mp4

and if we remove the absolute position of #call-screen, the whole screen repaint problem is gone.

Thank you Thinker!

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Yuren Ju [:yurenju] from comment #10)
> after traced with Thinker, we found it might be a bug on gecko nightly.
> please see below video, left is firefox stable (17), right is firefox nightly
> 
> https://www.dropbox.com/s/513tzzqhw2kz4qv/repaint.mp4
> 
> and if we remove the absolute position of #call-screen, the whole screen
> repaint problem is gone.
> 
> Thank you Thinker!

I use a nightly and even if the screen repaints is better this is still very hard to unlock the phone (the animation seems slow).


Josh, preventing accidental 'answer' should not make it harder to unlock my phone when I really want to do it! :)

A 2 steps action to answer a phone call is really painful... Sounds like a usability issue for me...

Comment 12

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

I tried to remove absolute position of #call-screen on unagi, it still repainted whole screen. investigating...

Comment 13

[Josh Carpenter [:jcarpenter]]

(In reply to Vivien Nicolas (:vingtetun) from comment #11)
> Josh, preventing accidental 'answer' should not make it harder to unlock my
> phone when I really want to do it! :)
> 
> A 2 steps action to answer a phone call is really painful... Sounds like a
> usability issue for me...

I'm sympathetic, believe me, but in this case the pain is caused primarily by the performance problem. Let's focus on fixing those first.

Also, while I agree that swipe+tap is a bit more complicated than the original design, it does prevent accidental inputs. And that is a real issue, based on feedback from TEF.

That said, if there's no way to make the swipe performant for v1, we may indeed need to explore alternatives, including removing the swipe from the incoming call screen.

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Yuren Ju [:yurenju] from comment #12)
> I tried to remove absolute position of #call-screen on unagi, it still
> repainted whole screen. investigating...

Can't we use Canvas instead of SVG  and make everything smooth as butter then?

Comment 15

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Yes we can, but if we use canvas:
1. Need to spend time to implement it
2. cannot confirm canvas animation performance with a phone call.

And we only have 1 week for C2. I'm trying to find solution with SVG Animation until tomorrow night. after that without solution, We should consider removing the swipe.

Comment 17

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Yuren Ju [:yurenju] from comment #15)
> Yes we can, but if we use canvas:
> 1. Need to spend time to implement it
> 2. cannot confirm canvas animation performance with a phone call.
> 
> And we only have 1 week for C2. I'm trying to find solution with SVG
> Animation until tomorrow night. after that without solution, We should
> consider removing the swipe.

I would say: this bug is a blocker because people can not answer. Let's remove the slide animations and open a new bug with the blocking-basecamp? flag in order to see if the slide animation is something that would block the release or not.

Let's see what Daniel think about that.

Comment 18

[Daniel Coloma:dcoloma]

Use Case: As a user I do not want my device to answer calls accidentally when device is locked (e.g. I have it in my pocket). 

The slider concept made its work quite well, it is a pity we needed to look for alternative solutions... It seems that current one is not working (or at least not performing well).

Can we:

 1/ Test if there is an alternative to make it perform?
 2/ Look for alternatives (given the times it seems better if UX/Dev work closely together) that perform well. 

I do not care that much if we remove this for the time being if we end-up at the end with an option that meets the use case (either if it's 1 or 2).

Comment 19

[steve]

We need to know what is causing the performance issue? is it the 2 gesture action? is it the affordance animation? if it is the affordance animation, what aspect of the animation is the problem?

I can think of one way to simplify the affordance animation ( with minimal redesign) but lets find out where the problem is first, then if we need to, design around that. Need some kind of diagnostic to pinpoint problem. Myself and Vicky will speak to Yuren as soon as we can.

I agree this danny and josh that we need a swipe, I think we all agree we would prefer a one action unlock/answer but last I heard that is not an option. So its a case of making this sing with minimal redesign.

Comment 20

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Yuren Ju [:yurenju] from comment #7)
> I extract lockscreen for dialer to an individual app, you can visit below
> link to install it:
> http://yurenju.github.com/swiper/wrapper.html
> 
> and FPS about 15~20FPS

I see about 25-30fps on this demo.  The performance is acceptable IMHO.  (Which is surprising, because this isn't a cheap effect to render on every frame.)

I also reproduce the full-screen invalidation.  That's almost certainly what's killing the performance of this animation.

We should start here by writing a patch to fix the whole-screen invalidation, and post that patch to this bug.  Then we can reevaluate the performance in a more realistic test.

Since it sounds like that patch has already been written, that should be easy :).

Comment 21

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Symbolicated profile of incoming call screen

Profile uploading seems to be broken atm, but you can take this data and upload it to

http://people.mozilla.com/~bgirard/cleopatra/

to see the results.

In the right part of the profile, we're spending more than 90% of the time repainting.

The main b2g process main thread is mostly idle while this runs.

Comment 22

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Great news! full-screen invalidation is caused by css table layout. there is the result which I removed table layout.

https://www.dropbox.com/s/wu8ny0lkxptf2gg/swiper-repaint.mp4

Comment 23

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #21)
> Created attachment 688038 [details]
> Symbolicated profile of incoming call screen
> 
> Profile uploading seems to be broken atm, but you can take this data and
> upload it to
> 

http://people.mozilla.com/~bgirard/cleopatra/#report=ec9d6c7445750e07f83f68de5c0c5e9cddadf5d6&filter=%255B%257B%2522type%2522%253A%2522RangeSampleFilter%2522%252C%2522start%2522%253A657%252C%2522end%2522%253A1995%257D%255D

> In the right part of the profile, we're spending more than 90% of the time
> repainting.
> 
> The main b2g process main thread is mostly idle while this runs.

Comment 24

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Yuren Ju [:yurenju] from comment #22)
> Great news! full-screen invalidation is caused by css table layout. there is
> the result which I removed table layout.
> 
> https://www.dropbox.com/s/wu8ny0lkxptf2gg/swiper-repaint.mp4

Can you post a patch for this?  Thanks!

Comment 25

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Attachment: patch for removing table layout

Comment 26

[Kai-Chih Hu [:khu]]

Yuren will provide a patch today.

Comment 27

[Victoria Gerchinhoren [:vicky]]

Lockscreen for incomming call should stay more or less like the idle lock screen but changing the middle part where it sits all the call information (user photo, name, phone label) and right now has a wrong layout and transition, maybe there is a better way to do it if you follow the original design and just change the middle part of it and we don't have that layer coming from the top of the screen.

See lock screen design: https://www.dropbox.com/s/b1grmhc949dcbrt/Answering01.png

Comment 28

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Attachment: patch for removing wallpaper and table layout

after tried lots of ways, we need to  remove wallpaper and table layout for performance.

Josh, please see the video and tell us agree or disagree this implementation without wallpaper.

without contact avatar:
https://www.dropbox.com/s/fe320zc94hrjy6p/remove-wallpaper.mp4

with contact avatar:
https://www.dropbox.com/s/4suy0betdllxeu4/remove-table-layout.mp4
  
and others please use this patch for measuring performance. if performance is acceptable and Josh agree implementation without wallpaper,  I will request review for this.

Comment 29

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Yuren Ju [:yurenju] from comment #28)
> and others please use this patch for measuring performance. if performance
> is acceptable and Josh agree implementation without wallpaper,  I will
> request review for this.

Good catch! ... I should have think of this earlier; animating a semi-transparent gradient over an image always hurts!

My 2 cents: instead of removing the contact image altogether, let's put a solid color background beneath the bouncing animation? That leave less room for the contact image but at least we will not need to remove it.

Comment 30

[Etienne Segonzac (:etienne)]

We're seeing a significant improvement with bug 818562 too.

10fps gain here, 10fps gain there... it might actually work :)

Comment 31

[Josh Carpenter [:jcarpenter]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #29)
> Good catch! ... I should have think of this earlier; animating a
> semi-transparent gradient over an image always hurts!
> 
> My 2 cents: instead of removing the contact image altogether, let's put a
> solid color background beneath the bouncing animation? That leave less room
> for the contact image but at least we will not need to remove it.

Agreed. Steve can your team provide an updated visual design with a solid block behind the unlock area?

Comment 32

[Josh Carpenter [:jcarpenter]]

Yuren, nice work :)

Comment 33

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 688199 [details] [diff] [review]
patch for removing wallpaper and table layout

Bug 817988 was tracked the visual design, so it's time to review :)

Comment 34

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 688199 [details] [diff] [review]
patch for removing wallpaper and table layout

r=me; I think you would need to disable setCallerContactImage() at L56 in order to completely remove the background image, if I am right, please do and add a comment mentioning XXX bug 817988 there. The wallpaper.image part should also be disabled rather than removed (with a XXX comment) since we will probably recycle it.

Comment 35

[steve]

Tried to get hold of Yuren and Josh earlier but time difference wasn't on our side unfortunately. However trying to decipher all the above comments into what I think we need, (until we chat) please see below.

To put a solid block under the skipping rope animation will cut off far too much of the contact photo and defeats the purpose of having the lightness of the curved line.  If the performance suck is the large transparency over an image ( which I think it is) and having a plain solid block under than animation helps. Vicki and I  are suggesting the below solution using the bouncing opaque block and a straight line.

This should also eliminate  a lot of time needed for animation refinements.

https://www.dropbox.com/sh/z0m53ijhf0clmhe/dOpdKvnnFc

I am happy with the move to a straight line ( although curved line had much more personality)  but would much prefer not having to use the block as it means a much heavier looking lock screen, however if that is where the problem is this should solve it. 

We can't do anymore without talking to Yuren or other.

Comment 36

[steve]

Here is also a quick/crude animation showing how the incoming call lock screen could animate.

https://www.dropbox.com/sh/nc4otcc86w753b2/-9gw-h9Qtu#/

As stated above, lets talk or celebrate depending.

Comment 37

[Dietrich Ayala (:dietrich)]

Hi Steve, who do you need info from?

Comment 38

[Josh Carpenter [:jcarpenter]]

(In reply to steve from comment #35)
> Tried to get hold of Yuren and Josh earlier but time difference wasn't on
> our side unfortunately. However trying to decipher all the above comments
> into what I think we need, (until we chat) please see below.
> 
> To put a solid block under the skipping rope animation will cut off far too
> much of the contact photo and defeats the purpose of having the lightness of
> the curved line.  If the performance suck is the large transparency over an
> image ( which I think it is) and having a plain solid block under than
> animation helps. Vicki and I  are suggesting the below solution using the
> bouncing opaque block and a straight line.
> 
> This should also eliminate  a lot of time needed for animation refinements.
> 
> https://www.dropbox.com/sh/z0m53ijhf0clmhe/dOpdKvnnFc
> 
> I am happy with the move to a straight line ( although curved line had much
> more personality)  but would much prefer not having to use the block as it
> means a much heavier looking lock screen, however if that is where the
> problem is this should solve it. 
> 
> We can't do anymore without talking to Yuren or other.

Works for me. Nice work on a short turn around! Steve, would we also use a straight line on the normal Lock screen?

Yuren, if we implement per the new layout, do you feel that will solve the performance problems?

Comment 39

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Sure, I can implement this design without SVG, and the performance should be better. I will submit attachment 688199 [details] [diff] [review] for closing this issue and let we discuss in Bug 817988.

Comment 40

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Tim, performance with contact avatar is okay but performance with wallpaper isn't, so we don't need to remove avatar.

Merged.

Comment 41

[steve]

(In reply to Josh from comment #38)

Yes we will also use a straight line on the normal Lock screen. See link below.

https://www.dropbox.com/s/vii8qf3vr01ofav/lock-straight-line_02.png

Comment 42

[sarsenyev]

Reviewed and verified on "Unagi"
Build ID:20130103070201
 "incoming call" screen.

The lock screen is response, so user is able to answer the call and "Incoming call" message appears