Closed Bug 1100610 Opened 6 years ago Closed 5 years ago
[Poppit] Long delay when transitioning to card view when in Poppit app
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
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?]
[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
Product: Tech Evangelism → Firefox OS
[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.
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)
(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.
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?
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+
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.
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
I only got this issue to repro on Poppit and the issue still occurs after rebooting
Removing polish keyword, its not clear yet how to fix this and it may not be trivial.
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?
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.
Can we update the target milestone? Thanks.
Moved to current sprint
Target Milestone: 2.2 S3 (9jan) → 2.2 S5 (6feb)
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
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1120974
Could you verify this is fixed?
You need to log in before you can comment on or make changes to this bug.