1072531 - [Facebook] Pressing the home button from facebook has performance issues

Status: RESOLVED DUPLICATE of bug 1076613

(Firefox OS Graveyard :: Performance, defect)

Description

[[:RJ]]

Attachment: log cat

Description:
When on facebook app, going to the home screen by pressing the home button there is a large lag between home button press and screen actually backing out of the app


Repro Steps:
1) Update a Flame to 20140924063013
2) Launch facebook < sign in with valid account 
3) Have phone in landscape mode >Press home button 

Actual:
A long delay before returning to screen, next screen is not orientated correctly 


Expected:
App is dismissed quickly with screen it goes to is working as intended 

Environmental Variables:
Device: Flame 2.1
Build ID: 20140924063013
Gaia: 020e6283a033e8fbcf65e7ed81c5b75ba0095f22
Gecko: d6b762814638
Version: 34.0a2 (2.1)
Firmware Version: 123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency: 4/4
See attached: logcat video clip: https://www.youtube.com/watch?v=papcWlT_16I&feature=youtu.be

Comment 1

[[:RJ]]

This issue DOES occur on Flame 2.2 kitkat  2.1(512mb) kitkat


Pressing the home button from facebook has performance issues 

Flame 2.2 KitKat base 
Environmental Variables:
Device: Flame Master
Build ID: 20140924013003
Gaia: ff6dbb006e4e60edba697639aa2a2a199b07069b
Gecko: 1e2993c99323
Version: 35.0a1 (Master)
Firmware Version: 123
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0



Flame 2.1 KitKat Base (512mb)

Environmental Variables:
Device: Flame 2.1
BuildID: 20140924000243
Gaia: 93a99bea0b40d81bd063f7d8b1964dc1ba35ba7b
Gecko: d7e31ecd48af
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

This does NOT occure on 2.0 kit kat

App is dismissed quickly with screen it goes to is working as intended 

Flame 2.0 kit kat base (319mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140924003005
Gaia: 263e3b201dca967ec5346e35901aa981ca47dce7
Gecko: 35d791e16d31
Version: 32.0 (2.0)
Firmware Version: 123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Marcia Knous [:marcia]]

I think it would be helpful to time the difference you are seeing between 2.0 and 2.1/2.2 so we can really see how significant the lag is.

Comment 3

[pete siphantong [:Petes]]

The Flame 2.1 KitKat Base (319mb) has a long lag about 5-7 seconds.

Flame 2.1 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20140930000203
Gaia: a00d102abfe8ae15c4fd14771efa2335c6d3b8d9
Gecko: cde28bd9a285
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

__________________________________________________________________________________________________________________________


The Flame 2.2 and the 2.0 kit kat base (319mb) seem to have a 3 second lag.

Flame 2.2 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20140930040206
Gaia: 77ef35f5429bc3dfe9ca192b9aacc3c0bf8857de
Gecko: 7c24470b6b3a
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0


Flame 2.0 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140930000204
Gaia: 5c2303ec4e367da060aa1b807d541a6549b3d72a
Gecko: 38a496c50d98
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

__________________________________________________________________________________________________________________________

The Flame 2.1 KitKat Base (512mb) had no lag on the latest build.

Flame 2.1 KitKat Base (512mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20140930000203
Gaia: a00d102abfe8ae15c4fd14771efa2335c6d3b8d9
Gecko: cde28bd9a285
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Based on comment 3, 2.1 has a very significant lag, whereas 2.0 and 2.2 still have large lag but not to the same extent. I would consider all branches as affected, updating tracking flags

[Blocking Requested - why for this release]:

I am also nominating this to block 2.0? because the time it takes to return to homescreen is very slow.

Comment 5

[bhavana bajaj [:bajaj]]

Hey Derek, do you see this behavior across other apps or is it FB only?

Comment 6

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

I am seeing similar behaviour across Twitter, Youtube, and Reddit as well. Although today the lag across all apps is less that it was when this bug was written, the animation when going to homescreen is still choppy and slow, and sometimes the animation is skipped all together.

Comment 7

[bhavana bajaj [:bajaj]]

:gwagner, do you know who can help here? This does nto look good, so we will need help reproducing and profiling this issue.

Comment 8

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Removing the regression keyword based on info found in comment 3. This performance issue can be seen across all branches, it is just less apparent in 2.0 and 2.2

Comment 9

[Dietrich Ayala (:dietrich)]

Triage reviewed and marking blocking+. Re-adding regression keyword because it's gotten worse.

Comment 10

[Gregor Wagner [:gwagner]]

Dale, can you take a look here?

Comment 11

[Dale Harvey (:daleharvey)]

Taking a look, any transition back to the homescreen from a landscape layout is extremely slow, I have seen longer times on 2.1 since I switched Gecko, but only intermittently, it looks like between the 3 branches its generally around 3 seconds

One issue that I have only seen with 2.1 Gecko is as in the video, the homescreen looks to have been redrawn due to the orientation change, but since its portrait only it shouldnt need to do that, I wouldnt mind a bit more background into the issues because this is going to be a fairly complicated problem to fix

Alive, my main question is, since we cant lock orientation per application, do we do anything to avoid orientation locked apps redrawing temporarily (or I guess more broadly, can you give me a little intro into how the orientation locking works / what may be going wrong here)

Cheers

Comment 12

[Etienne Segonzac (:etienne)]

2 cents:
* maybe this [1] does not apply properly to inline activities launched by the homescreen (looks like a collection is opened in the video)
* wonder if we can tweak [2]


[1] https://github.com/mozilla-b2g/gaia/blob/b0befba79285e5931c91c900736c16439349b100/apps/system/js/app_window.js#L794
[2] https://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#862

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Dale Harvey (:daleharvey) from comment #11)
> Taking a look, any transition back to the homescreen from a landscape layout
> is extremely slow, I have seen longer times on 2.1 since I switched Gecko,
> but only intermittently, it looks like between the 3 branches its generally
> around 3 seconds
> 
> One issue that I have only seen with 2.1 Gecko is as in the video, the
> homescreen looks to have been redrawn due to the orientation change, but
> since its portrait only it shouldnt need to do that, I wouldnt mind a bit
> more background into the issues because this is going to be a fairly
> complicated problem to fix
> 
> Alive, my main question is, since we cant lock orientation per application,
> do we do anything to avoid orientation locked apps redrawing temporarily (or
> I guess more broadly, can you give me a little intro into how the
> orientation locking works / what may be going wrong here)
> 
> Cheers

When switching app occurs:
* The background/next app switches to opening state.
** If the background/next app is homescreen it will lock the orientation in this stage.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_transition_controller.js#L251
* The active/current app switches to closing state.
* After opening transition ends, the background/next app enters opened state.
** If the next app is not homescreen, it will lock the orientation in this stage.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_transition_controller.js#L270
(Maybe it is because we didn't block this.isHomescreen here? So it locks twice to introduce two reflow.)

Comment 14

[Dale Harvey (:daleharvey)]

So a fairly large part of this delay is the waitForRepaint that times out, https://gist.github.com/daleharvey/7d9e79be3bdc6956c742 is a simple patch that removes the wait on the homescreen and speeds this up significantly, I havent found any visible flashes caused by this.

I cant find any specific regression, between 2.0 / 2.1 and master a bunch of code has changed and there isnt any indication whether this happens in gecko or gaia plus its fairly intermittent, I can get large delays on master and see shorter ones on 2.1 occasionally, it does seem like 2.1 is worse but I dont think there is much we can do except speed this up.

Comment 15

[Dale Harvey (:daleharvey)]

So I think the above patch can create an improvement, Alive is there a safe way to not have to wait for repaint if the homescreen is immediately visible? (as it seems to be when it hasnt been killed)

Another issue is that the collection app definitely reflows entirely when switching, I assume that the the wanted flow is

 1. homescreen (+activity) is active, lock portrait
 2. Open facebook, setVisible false on homescreen (+activity)
 3. unlock orientation, facebook goes landscape
 4. Press home, lock orientation to portait
 5. setVisible true on homescreen (+activity)

and that because setvisible was false while the orientation wasnt locked, the underlying windows shouldnt need to reflow? and an early setVisible(true) before the orientationlock happens will break that? or is the reflow just impossible to get rid of?

Sorry for the questions, fairly unfamiliar with this code

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Dale Harvey (:daleharvey) from comment #15)
> So I think the above patch can create an improvement, Alive is there a safe
> way to not have to wait for repaint if the homescreen is immediately
> visible? (as it seems to be when it hasnt been killed)

Actually visible does not mean paint is ready. It's synchronous API but the visibility state change is asynchronous, as well as the rendering state.

But if there is no visual flash from your patch I think we are safe to go.

> 
> Another issue is that the collection app definitely reflows entirely when
> switching, I assume that the the wanted flow is
> 
>  1. homescreen (+activity) is active, lock portrait
>  2. Open facebook, setVisible false on homescreen (+activity)
>  3. unlock orientation, facebook goes landscape
>  4. Press home, lock orientation to portait
>  5. setVisible true on homescreen (+activity)
> 
> and that because setvisible was false while the orientation wasnt locked,
> the underlying windows shouldnt need to reflow? and an early
> setVisible(true) before the orientationlock happens will break that? or is
> the reflow just impossible to get rid of?

Hmm... I cannot reproduce the video stuff.
My collection is closed/killed once I press the home button in landscape facebook.

I think it's intentional here to kill the front window when pressing home button:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/homescreen_window.js#L196

I am not sure why this doesn't work for you (and the video).
1. Is it really necessary to keep the collection activity?
2. If (1) is true, what happens to the collection activity to cause AppWindow.prototype.resize to be called? It seems a timing issue to me - maybe we are going to homescreen too early before the orientation is changed, so it just resizes the collection activity.

That is to say, we could put console.trace in AppWindow.prototype.resize to see who and when is calling that for the collection activity.

> 
> Sorry for the questions, fairly unfamiliar with this code

It might be a nontrivial bug but it's easy to turn on AppWindow.prototype._DEBUG (or the global var DEBUG = ture in app_window.js top) to observe the logs.

Comment 17

[Dale Harvey (:daleharvey)]

Thanks that helps a lot, and yeh I have been reading the logs from DEBUG in app_window, I can see whats happening but its trying to infer what could / should be happening, you have helped a lot cheers

Comment 18

[Dale Harvey (:daleharvey)]

> 1. Is it really necessary to keep the collection activity?

This behaviour changed in https://bugzilla.mozilla.org/show_bug.cgi?id=1076613, prior the collection was kept open, now its removed which looks like the correct behaviour, it also removes a lot of busy work the apps are doing while also reorientating.

I believe my patch (or similiar) can help switch to homescreen times a lot, but I want to make sure to definitely cause any redraws / flashes, so I think its safer to uplift then I can take a look

Comment 19

[Dale Harvey (:daleharvey)]

So 1076613 is nominated for uplift, it improves the speed of the transition. Its still extremely slow however it looks very much the same as what is in master, not specific to 2.1, I dont think its safe to be doing performance improvements of code that has diverged from master so much, although now if we want it to be faster still we can do the improvements on master and uplift, but that would be a seperate bug, Marking as a dupe