[Midori 2.0][Performance][TP]The interface of the game is abnormally when it's horizontal screen

RESOLVED DUPLICATE of bug 998916

Status

()

P2
normal
RESOLVED DUPLICATE of bug 998916
4 years ago
4 years ago

People

(Reporter: sync-1, Assigned: jerry)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 unaffected, b2g-v2.2 unaffected)

Details

(Whiteboard: [Triage_EM_20])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
FFOS 2.0
 mozilla build id:20141019000201
 
 +++ This bug was initially created as a clone of Bug #827074 +++
 Created an attachment (id=999176)
 Screenshot
 
 DEFECT DESCRIPTION:
 ->The interface of the game is abnormally when it's horizontal screen. 
 Regression: FFOS 1.3 is OK.
 
  REPRODUCING PROCEDURES:
 1. Install "Skate Jumper" or "Fly with my car"...
 2. Play game
 3. press home key to idle screen
 4. reopen game.
 ->The interface of the game is abnormally.(KO)
 
  EXPECTED BEHAVIOUR:
 ->The interface of the game is normally when it's horizontal screen.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 100%
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #827074 description ++++++++++
 
 		
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

4 years ago
[Blocking Requested - why for this release]:
FFOS 1.3 is OK, and if user switch game to the back, the only thing that the user can do is to close App.
blocking-b2g: --- → 2.0?
Flags: needinfo?(whuang)
(Reporter)

Comment 2

4 years ago
Created attachment 8515841 [details]
Screenshot

Comment 3

4 years ago
2.0 tag candidate since it's a regression from 1.3. However need log.

Hi Chenguoqiang, would you provide log of it? Does it only happen with specific game?
Flags: needinfo?(whuang) → needinfo?(Chenguoqiang)
Whiteboard: [Triage_EM_20]

Comment 4

4 years ago
[Triage] tag for 2.0.

Hi Peter: would you help look this issue? Thank you!
Flags: needinfo?(pchang)

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+

Comment 5

4 years ago
Quick question, could we reproduce this with master build?

Comment 6

4 years ago
(In reply to peter chang[:pchang][:peter] from comment #5)
> Quick question, could we reproduce this with master build?

I couldn't reproduce in local. Could someone help to confirm? And then I suggest to use regression-window to identify the problem.
Flags: needinfo?(pchang)

Comment 7

4 years ago
Created attachment 8517180 [details]
SkateJumper.txt
Flags: needinfo?(Chenguoqiang)

Comment 8

4 years ago
Dear Wesly,

Not all app have this problem, I test five game "star breaker", "ball tronik", "Skate Jumper", "Flay with my car", "Maya", "ball tronik". only "ball tronik" seemed can play normally.
(In reply to Guoqiang.CHEN from comment #7)
> Created attachment 8517180 [details]
> SkateJumper.txt

Hi Jerry,
  It looks like related to WebGL context lost issue based on the above attached log.
Would you suggest to uplift related patch from master to 2.0?

I/Gecko   ( 4853): WebGL(0xb300e800)::ForceLoseContext
I/Gonk    (  214): Setting nice for pid 4920 to 18
I/Gonk    (  214): Changed nice for pid 4920 from 0 to 18.
I/Gecko   ( 4853): WebGL(0xb300e800)::ForceRestoreContext
Flags: needinfo?(hshih)
Since I couldn't reproduce this in master in comment 6, add regression-window wanted.
Flags: needinfo?(hshih)
Keywords: regressionwindow-wanted
We confirm the bug and branch check first before a regression window can be attempted.
Keywords: regressionwindow-wanted → qawanted
Issue is reproducible on Flame 2.0 and Flame base image v188-1 only.

Observed behavior: Pressing Home button while in active gameplay of Sky Jumper and then re-enter game causes the game to show a white screen with weird yellow-ish graphics. The user can only kill the game via card view and re-launch to see the game in its normal state.

Device: Flame 2.0
BuildID: 20141105063630
Gaia: e19ba2a049f192a560c6e63a0cc213b0353f1a02
Gecko: 2c2d1f552ff6
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-----

Issue is NOT reproducible on Flame 2.1 and Flame 2.2 master.

Observed behavior: Sky Jumper resumes without issue after pressing Home button and re-enter the game.

Device: Flame 2.1
BuildID: 20141105063632
Gaia: 445656e36d14054d46a8f201dc68d76da8cfa281
Gecko: e7efb38a6477
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2 Master
BuildID: 20141105043145
Gaia: bc843fbf8973c8e124e5668bb2752f5d025fb488
Gecko: 72ae882fce1a
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(In reply to Pi Wei Cheng [:piwei] from comment #13)
> Issue is reproducible on Flame 2.0 and Flame base image v188-1 only.
> 
> Observed behavior: Pressing Home button while in active gameplay of Sky
> Jumper and then re-enter game causes the game to show a white screen with
> weird yellow-ish graphics. The user can only kill the game via card view and
> re-launch to see the game in its normal state.
> 
> Device: Flame 2.0
> BuildID: 20141105063630
> Gaia: e19ba2a049f192a560c6e63a0cc213b0353f1a02
> Gecko: 2c2d1f552ff6
> Version: 32.0 (2.0)
> Firmware: V188-1
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> -----
> 
> Issue is NOT reproducible on Flame 2.1 and Flame 2.2 master.
> 
> Observed behavior: Sky Jumper resumes without issue after pressing Home
> button and re-enter the game.
> 
> Device: Flame 2.1
> BuildID: 20141105063632
> Gaia: 445656e36d14054d46a8f201dc68d76da8cfa281
> Gecko: e7efb38a6477
> Version: 34.0 (2.1)
> Firmware: V188-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
> 
> Device: Flame 2.2 Master
> BuildID: 20141105043145
> Gaia: bc843fbf8973c8e124e5668bb2752f5d025fb488
> Gecko: 72ae882fce1a
> Version: 36.0a1 (2.2 Master)
> Firmware: V188-1
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Asking for regression window again.
Keywords: regressionwindow-wanted
(In reply to peter chang[:pchang][:peter] from comment #6)
> (In reply to peter chang[:pchang][:peter] from comment #5)
> > Quick question, could we reproduce this with master build?
> 
> I couldn't reproduce in local. Could someone help to confirm? And then I
> suggest to use regression-window to identify the problem.

Peter - are you asking for a regular window or a reverse (fixed) window to identify what fixed this in 2.2?
Flags: needinfo?(pchang)
Keywords: regressionwindow-wanted
(In reply to Joshua Mitchell [:Joshua_M] from comment #15)
> (In reply to peter chang[:pchang][:peter] from comment #6)
> > (In reply to peter chang[:pchang][:peter] from comment #5)
> > > Quick question, could we reproduce this with master build?
> > 
> > I couldn't reproduce in local. Could someone help to confirm? And then I
> > suggest to use regression-window to identify the problem.
> 
> Peter - are you asking for a regular window or a reverse (fixed) window to
> identify what fixed this in 2.2?
Not sure the regular window you mentioned above, I'm asking the fixes in 2.2 because this issue only could be reproduced in 2.0 not in 2.2(master). Can I use regressionwindow-wanted for this kind of request?
Flags: needinfo?(pchang) → needinfo?(jmitchell)
> > Peter - are you asking for a regular window or a reverse (fixed) window to
> > identify what fixed this in 2.2?
> Not sure the regular window you mentioned above, I'm asking the fixes in 2.2
> because this issue only could be reproduced in 2.0 not in 2.2(master). Can I
> use regressionwindow-wanted for this kind of request?

Thank you for clarifying - yes, this tag will be fine to request that - just try and use clear language; you had said " I suggest to use regression-window to identify the problem."   - which is what normal regression-windows do, identify the problem or issue that caused the regression. When asking for a 'reverse' or 'fixed' window we are actually identifying the FIX and not the cause.
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: pcheng
mozilla-inbound reverse regression window:

Last Broken Environmental Variables:
Device: Flame
BuildID: 20140624013753
Gaia: 45479c07cb6ba8c733093d6ee32c767c090c9a28
Gecko: 7320004519ea
Version: 33.0a1 (2.1 master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Working Environmental Variables:
Device: Flame
BuildID: 20140624015449
Gaia: 45479c07cb6ba8c733093d6ee32c767c090c9a28
Gecko: e36cf3ad5704
Version: 33.0a1 (2.1 master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Gaia is the same, so it's a Gecko commit that fixed this issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7320004519ea&tochange=e36cf3ad5704

Possibly fixed by bug 998916?
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Possibly fixed by bug 998916 - Jerry can you investigate and see about uplifting that patch to 2.1 to fix this issue?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(hshih)
edit - uplifting that patch to 2.0 to fix this issue
QA Contact: pcheng
Jeff, this issue is related to the context lost when we turn off the screen.
B2G will send the "heap-minimize" when we turn off the screen. At this time, webgl will release the context. I think the game in comment 0 does not handle the lost context for webgl.

In patch[1], I defer the webgl context restore timing and I also change the pressure condition form "heap-minimize" to "memory-pressure". So we will not always lose device when the screen off. This patch in bug 998916 depend on your Bug 980178 (cleanup context handling).
Should we uplift both Bug 980178 and bug 998916? Or just have another fix to change the pressure condition?
What do you think?

[1]
https://bugzilla.mozilla.org/attachment.cgi?id=8444287&action=diff#a/content/canvas/src/WebGLContextValidate.cpp_sec2
Flags: needinfo?(jgilbert)
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #21)
> Jeff, this issue is related to the context lost when we turn off the screen.
> B2G will send the "heap-minimize" when we turn off the screen. At this time,
> webgl will release the context. I think the game in comment 0 does not
> handle the lost context for webgl.
> 
> In patch[1], I defer the webgl context restore timing and I also change the
> pressure condition form "heap-minimize" to "memory-pressure". So we will not
> always lose device when the screen off. This patch in bug 998916 depend on
> your Bug 980178 (cleanup context handling).
> Should we uplift both Bug 980178 and bug 998916? Or just have another fix to
> change the pressure condition?
> What do you think?
> 
> [1]
> https://bugzilla.mozilla.org/attachment.cgi?id=8444287&action=diff#a/content/
> canvas/src/WebGLContextValidate.cpp_sec2

Prefer uplifting rather than one-off patches.
Flags: needinfo?(jgilbert)
I had uplifted the bug 998916 to 2.0 and tested the game "Skate Jumper" and "Fly with my car" in comment 0.
It seems work well.

Bug 998916 will be uplifted to 2.0.
Flags: needinfo?(hshih)

Comment 24

4 years ago
Jerry, assign to you. If you think this bug is a duplicate of bug 998916, you can check the status of this bug. Or close it after uplifting bug 998916.
Component: Gaia → Canvas: WebGL
Product: Firefox OS → Core
(Assignee)

Updated

4 years ago
Assignee: nobody → hshih
Status: NEW → ASSIGNED
Hi Joshua,

Could please apply the patch https://bugzilla.mozilla.org/attachment.cgi?id=8520418 in bug 998916 and test again?
I try the same games in comment 0, and they works well.
Flags: needinfo?(jmitchell)
QA-Wanted: see comment 25
Flags: needinfo?(jmitchell)
Keywords: qawanted
sorry, I did not look at that request close enough.

Sorry, No; we can not do that request here. In this lab we are only able to apply Gaia patches that have been uploaded to Github.

Leaving QA-wanted tag for another qa lab with those capabilities to pick up this task.
The patch in bug 998916 is already landed.
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/1b1134490959

Please test the comment 0 again if you guys can get the last binary gecko build.
Flags: needinfo?(jmitchell)
I'll have someone on the QA-Wanted team look into this
Flags: needinfo?(jmitchell)
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #28)
> The patch in bug 998916 is already landed.
> https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/1b1134490959

The original issue is fixed. Skate Jumper can now correctly resume following STR.

Device: Flame 2.0
BuildID: 20141118044626
Gaia: 1ede2666f1e6c1b3fd3b282011caf0cbc59544b0
Gecko: bde95439014c
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

----------

However I found an issue where the orientation can become messed up after locking, unlocking the device and enter game in portrait. The issue appears to be irrelevant to this fix; I think it COULD be caused by the fix for bug 1089529 because I flashed to a build on 11/14 where 1089529 landed on 2.0 and this fix (1092975) hasn't landed and issue is reproducible.

See video for issue demonstration:

http://youtu.be/xn781dUPVZg

At the beginning of the video shows the game correctly forcing landscape orientation upon entering (device is put to portrait mode throughout video), but after locking the device it causes adverse effects on the game and homescreen.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.0: affected → fixed
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
bug 998916 fix the webgl context problem in comment 0(please check comment 30). The other problem in comment 30 is not related to this fix.

Mark this bug as duplicate.

Pi Wei, maybe you should create another bug to trace the issue.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(pcheng)
Resolution: --- → DUPLICATE
Duplicate of bug: 998916
Filed bug 1101664 to track the issue.
Flags: needinfo?(pcheng)
See Also: → bug 1101664
You need to log in before you can comment on or make changes to this bug.