Closed Bug 1089040 Opened 5 years ago Closed 5 years ago
[SHB] Pulling down utility tray over SIM PIN dialog causes graphics artifacts
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]
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.
This looks like a driver/low level issue. What base image are you on, and does it show up on a different base image?
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
> 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.
(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+
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
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Please request b2g34 approval on this when you get a chance :)
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
Attachment #8513732 - Flags: approval-mozilla-b2g34?
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.