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

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Michael Henretty [:mikehenrty][:mhenretty]]

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.

Comment 1

[Michael Henretty [:mikehenrty][:mhenretty]]

Note: this potentially be worked around if we decide to fix bug 1089010 by disabling utility tray while the SIM PIN dialog is open.

Comment 2

[Michael Henretty [:mikehenrty][:mhenretty]]

[Blocking Requested - why for this release]:
This looks pretty bad, see video for an idea.

Comment 3

[Michael Henretty [:mikehenrty][:mhenretty]]

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.

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

This looks like a driver/low level issue.  What base image are you on, and does it show up on a different base image?

Comment 5

[Guillaume Marty [:gmarty]]

Also potentially related to Bug 1088057.

Comment 6

[Michael Henretty [:mikehenrty][:mhenretty]]

(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.

Comment 7

[Benoit Girard (:BenWa)]

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.

Comment 8

[Benoit Girard (:BenWa)]

Attachment: 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.

Comment 9

[Dietrich Ayala (:dietrich)]

Candice, is there a device being shipped with 2.1 that requires software home button on by default? If so, this will block.

Comment 10

[Benoit Girard (:BenWa)]

(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.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 12

[Gregor Wagner [:gwagner]]

[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.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 14

[Benoit Girard (:BenWa)]

Attachment: Fix opacity calculations in HWC

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.

Comment 15

[Benoit Girard (:BenWa)]

Attachment: Fix opacity calculations in HWC v2

Added a comment to make it more clear why this check is there

Comment 16

[Benoit Girard (:BenWa)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0f69fbc0d65d

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0f69fbc0d65d

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Please request b2g34 approval on this when you get a chance :)

Comment 19

[Benoit Girard (:BenWa)]

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

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6f791ce8cac8

Comment 21

[Duane Dixon [:ddixon]]

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