[Poppit] Long delay when transitioning to card view when in Poppit app

RESOLVED DUPLICATE of bug 1120974

Status

Firefox OS
Gaia::System::Window Mgmt
RESOLVED DUPLICATE of bug 1120974
4 years ago
3 years ago

People

(Reporter: SalvadorR, Assigned: sfoster, NeedInfo)

Tracking

({perf, verifyme})

unspecified
2.2 S5 (6feb)
perf, verifyme

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

Details

(Whiteboard: [2.1-exploratory-3] [systemsfe], URL)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8524125 [details]
logcat_20141117_1406.txt

Description:
If user transitions to card view when in Poppit app, there will be a long delay before the function occurs.

Repro Steps:
1) Update a Flame device to BuildID: 20141117001201
2) Go to marketplace and download Poppit app
3) Open Poppit app and hold down Home button
4) Observe the app transitioning to card view
  
Actual: Long delay to get to card view
  
Expected: 
No long delay
  
Environmental Variables:
Device: Flame 2.1 (319mb) KK Shallow Flash
BuildID: 20141117001201
Gaia: 81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko: 3572aa3e6766
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 5/5
See attached: Logcat, Video
http://youtu.be/xVdC44m2oX4
(Reporter)

Comment 1

4 years ago
This issue also occurs on Flame 2.0 and  Flame 2.2

Results: Delay occurs when going to card view

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141117000200
Gaia: 086a668942292168f312b3bb53e275fa0886fab1
Gecko: a57b299c5cf2
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.2

Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141117040203
Gaia: ddf5b92f43ec27c93ad4fea4fd1207da8936b8e7
Gecko: 21b745197618
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
[Blocking Requested - why for this release]:

This seems like more of a window management bug. Changing the product and component to reflect this. Also nominating to block 2.0 on this. The transition to card view can take around 5 seconds.This seems to be happening because this is a game app that requires a lot of memory, and could happen on other apps that are memory hogs.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Component: Preinstalled B2G Apps → Gaia::System::Window Mgmt
Flags: needinfo?(dharris)
Product: Tech Evangelism → Firefox OS

Comment 3

4 years ago
[Blocking Requested - why for this release]:

[Triage] nom to 2.1? considering current 2.0 phase.
blocking-b2g: 2.0? → 2.1?
(In reply to Wesly Huang from comment #3)
> [Blocking Requested - why for this release]:
> 
> [Triage] nom to 2.1? considering current 2.0 phase.

Let me NI :alive to see what we can do here.
Flags: needinfo?(alive)

Comment 5

4 years ago
Brogan, can you get a memory dump?  You can use firewatch to capture what's happening.  also, does this happen with other apps?   and what happens if you rebooted?
I don't think we have something to do - the delay should come from transferring from landscape to portrait.

Sam, what do you think?
Flags: needinfo?(alive) → needinfo?(sfoster)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> I don't think we have something to do - the delay should come from
> transferring from landscape to portrait.
> 
(And it's known platform issue)
(Assignee)

Comment 8

4 years ago
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> > I don't think we have something to do - the delay should come from
> > transferring from landscape to portrait.
> > 
> (And it's known platform issue)

I agree we've done about all we can do on the system/Gaia side. We no longer block on waiting for the screenshot. It might be interesting to profile what's going on during that delay though if this is readily reproducible.
Flags: needinfo?(sfoster)
Given this isn't a new regression lets try fixing this in the next release instead.
blocking-b2g: 2.1? → 2.2?
Can we get a profile here?
Keywords: polish

Updated

4 years ago
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3] [systemsfe]
qawanted for branch checks, and then possible regression window.
blocking-b2g: 2.2? → 2.2+
Keywords: qawanted
Random stab in the dark - I think this delay is caused by the switch from landscape to portrait before bringing the card-view up. Have we checked that we aren't rotating and causing the app to repaint before bringing the chooser up (by, for example, switching it for a screenshot before rotating)? Or could we have a landscape-oriented chooser?
(In reply to Michael Henretty [:mhenretty] from comment #11)
> qawanted for branch checks, and then possible regression window.

Hi Michael - Branch checks were already done at comment 1; 2.0, 2.1, 2.2 were all affected so this is determined not a regression - no window available.
Keywords: qawanted
Assignee: nobody → sfoster
Adding 'perf' keyword to this - as previously discussed this seems to be a long-standing issue with transitioning out of high-memory apps (especially landscape to portrait). 

Also adding NI to reporter to address the memory dump request from comment 5
Flags: needinfo?(srapanan)
Keywords: perf
(Reporter)

Comment 15

4 years ago
I only got this issue to repro on Poppit and the issue still occurs after rebooting
Flags: needinfo?(srapanan)
(Assignee)

Comment 16

4 years ago
Removing polish keyword, its not clear yet how to fix this and it may not be trivial.
Keywords: polish
Target Milestone: --- → 2.2 S3 (9jan)
(Assignee)

Comment 17

4 years ago
Created attachment 8546776 [details]
profile_captured.sym

I can reproduce this, but the delay seems to be more like 1/2 to 1sec on my flame, vs. the 5s reported. I'm attaching a profile in which hold the home button while on the Poppit app to show the task manager. My testing here agrees with the observations in bug 1107139 that fullscreen apps seem to be slower than others to go into the background.
Ted, can you help Sam out and try to debug?
Flags: needinfo?(tclancy)
(Assignee)

Comment 19

4 years ago
This seems to be related to bug 1107139, may even turn out to be a dupe, so check that bug too for investigation to-date. Thx
I might have a go at this when I'm back in Toronto, where I can chat to the graphics team members about it.

Updated

3 years ago
Flags: needinfo?(tclancy)

Comment 21

3 years ago
Can we update the target milestone? Thanks.
Flags: needinfo?(cserran)
(Assignee)

Comment 22

3 years ago
Moved to current sprint
Flags: needinfo?(cserran)
Target Milestone: 2.2 S3 (9jan) → 2.2 S5 (6feb)
(Assignee)

Comment 23

3 years ago
I can no longer reproduce this. I've tried with Poppit and a few other games, also some of the built-in apps that are also fullscreen and landscape. I think this was fixed by bug 1120974.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1120974
(Assignee)

Updated

3 years ago
Keywords: verifyme
Could you verify this is fixed?
Flags: needinfo?(srapanan)
You need to log in before you can comment on or make changes to this bug.