Closed Bug 1089040 Opened 5 years ago Closed 5 years ago

[SHB] Pulling down utility tray over SIM PIN dialog causes graphics artifacts

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla36
blocking-b2g 2.1+
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: mikehenrty, Assigned: BenWa)

References

()

Details

(Whiteboard: [shb-enabled])

Attachments

(2 files, 1 obsolete file)

STR:

1.) Enable SHB
2.) Enable SIM PIN on simcard
3.) Open SIM pin dialog (lock->unlock phone, or open Messages app)
4.) Pull down Utility Tray

Expected results:
Utility tray opens without flashing.

Actual results:
Whole screen flashes when opening or closing the utility tray. If you enabled FPS in developer HUD, you will see the graphic artifacts in the video.
Note: this potentially be worked around if we decide to fix bug 1089010 by disabling utility tray while the SIM PIN dialog is open.
[Blocking Requested - why for this release]:
This looks pretty bad, see video for an idea.
blocking-b2g: --- → 2.1?
Whiteboard: [shb-enabled] → [shb-enabled][systemsfe]
Whiteboard: [shb-enabled][systemsfe] → [shb-enabled
Component: Gaia::System::Window Mgmt → Graphics
Product: Firefox OS → Core
Whiteboard: [shb-enabled → [shb-enabled]
Milan, putting this on your radar, since it will probably be a blocker. There is a good chance it is the same issue as bug 1085593, but I don't have the expertise to know for sure.
Flags: needinfo?(milan)
This looks like a driver/low level issue.  What base image are you on, and does it show up on a different base image?
Flags: needinfo?(milan)
Also potentially related to Bug 1088057.
(In reply to Milan Sreckovic [:milan] from comment #4)
> This looks like a driver/low level issue.  What base image are you on, and
> does it show up on a different base image?

I'm using 188.
It does in fact seem very related to bug 1085593. I'm tentatively looking into this bug first because it reproduces for a long period of time and not just one frame like bug 1085593 making analysis easier.
Assignee: nobody → bgirard
Attached file Offending layer tree
> PaintedLayerComposite (0xaad91000) [shadow-visible=< (x=0, y=0, w=480, h=45); (x=0, y=788, w=480, h=66); >] [bounds=(x=0, y=0, w=480, h=854)] [visible=< (x=0, y=0, w=480, h=45); (x=0, y=788, w=480, h=66); >] [opaqueContent] [valid=< (x=0, y=0, w=480, h=45); (x=0, y=788, w=480, h=66); >]

This is the layer that's causing the problem. This is hitting the HWC path with a complex region since the region has two rects. This layer is the status bar + SHB which is missing the center. Disabling HWC support for complex region makes this bug go away.
Candice, is there a device being shipped with 2.1 that requires software home button on by default? If so, this will block.
Flags: needinfo?(cserran)
(In reply to Dietrich Ayala (:dietrich) from comment #9)
> Candice, is there a device being shipped with 2.1 that requires software
> home button on by default? If so, this will block.

I agree this should block. It's a nasty graphics bug so who knows where it will show up.
I'm not aware of a 2.1 device that requires the software home button.  For 2.2, yes.  I appreciate that we may hit this issue in other workflows, and if we do, and the workflow is a blocking one, we should 2.1+.  In the meantime, I only see this as a 2.2 blocker.
[Blocking Requested - why for this release]:

(In reply to Milan Sreckovic [:milan] from comment #11)
> I'm not aware of a 2.1 device that requires the software home button.  For
> 2.2, yes.  I appreciate that we may hit this issue in other workflows, and
> if we do, and the workflow is a blocking one, we should 2.1+.  In the
> meantime, I only see this as a 2.2 blocker.

The tako device has the SHB. So our main device has it.
Sorry, my bad, too many numbers, I mixed up 2.0 and 2.1.  Since that's sorted out, save everybody an extra click and make this 2.1+ now.
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(cserran)
Attached patch Fix opacity calculations in HWC (obsolete) — Splinter Review
The problem is displayFrame is the *bounds*, so if you have a layer with a hole in it, like we get when we enable the SHB by creating a layer that's the top system bar and the bottom SHB with a transparent hole in the middle, then we think the bounds are opaque when really just the top/bottom are opaque. This was causing only the top most layer to be rendered leaving the rest of the screen unpainted.
Attachment #8513709 - Flags: review?(sotaro.ikeda.g)
Attachment #8513709 - Flags: review?(sotaro.ikeda.g) → review+
Added a comment to make it more clear why this check is there
Attachment #8513709 - Attachment is obsolete: true
Attachment #8513732 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/0f69fbc0d65d
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Please request b2g34 approval on this when you get a chance :)
Flags: needinfo?(bgirard)
Comment on attachment 8513732 [details] [diff] [review]
Fix opacity calculations in HWC v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 981732
User impact if declined: We can render an incomplete garbage frame
Testing completed: Just hit central, fixes the problem locally.
Risk to taking this patch (and alternatives if risky): It's fairly low. Under a subset of cases I'm turning off a fast path (Culling) that was introduced in bug 981732. I'm only turning it off for the case where the code is provably incorrect.
String or UUID changes made by this patch: None
Flags: needinfo?(bgirard)
Attachment #8513732 - Flags: approval-mozilla-b2g34?
Depends on: 981732
Attachment #8513732 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Issue is verified fixed in Flame 2.2, 2.1 builds (Full Flash, nightly, 319 MB memory). 

Actual Results: There are no graphical errors when user pulls down utility tray over SIM pin dialogue. 

Device: Flame 2.2
BuildID: 20141103040202
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 5999e92e89ff
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.1
BuildID: 20141103001220
Gaia: 027a7de0c95320cea0579bfd1a4ceef3e9038f34
Gecko: ffecb2be228b
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.