1120870 - [Flame][Video]There is a small transparent area on video menu view.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Video, defect)

Description

[Elie]

[1.Description]:
[Flame][v2.2][Video]There is a small transparent area on video menu view after switching the device to landscape view.
Attchment:VIDEO0229[1].mp4 and logcat.txt
Happen time:1:37

[2.Testing Steps]: 
Precondition:There are some video in phone storage
1.Launch Video
2.Tap a video to play
3.Tap the video to invoke play control bar
4.Tap the menu icon on top right
5.Switch to landscape


[3.Expected Result]: 
5.There should be no transparent area on video menu view.

[4.Actual Result]: 
5.There is a small transparent area on video menu view.

[5.Reproduction build]: 
Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2c37b89bdd86
Build-ID        20150112153951
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150112.194842
FW-Date         Mon Jan 12 19:48:52 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

Comment 1

[Elie]

Attachment: logcat.txt

Comment 2

[Elie]

Attachment: VIDEO0229[1].mp4

Comment 3

[Eric Chang [:ericcc] [:echang]]

Hi Eli, Is that also happening on V2.1, if no, that will be a regression, thanks.

Comment 4

[Elie]

(In reply to Eric Chang [:ericcc] [:echang] from comment #3)
> Hi Eli, Is that also happening on V2.1, if no, that will be a regression,
> thanks.
Hi Eric
This issue dose not exist on Flame 2.1:
Gaia-Rev        77c57eb8a985d5cbd34a597fb1b978ba6e205af6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/452a023ae7b2
Build-ID        20150118001331
Version         34.0
Device-Name     flame
FW-Release      4.4.2

Comment 5

[Eric Chang [:ericcc] [:echang]]

Thanks.
Set blocking 2.2?  for regression.

Comment 6

[Hema Koka [:hema]]

Punam or Russ,

Can one of you check this?

Thanks
Hema

Comment 7

[Punam Dahiya [:pdahiya]]

I am able to replicate the issue reported in 2.2. Looking into it.

Comment 8

[Punam Dahiya [:pdahiya]]

Here are my findings so far, the transparent area seen in landscape view after tapping options icon on top right is from video#player. 

On debugging so far I haven't seen any changes in Video app css which are 2.2 specific that could have caused this regression. This could be a graphic issue. Setting NI flag for Russ and David if they know of 2.2 Video player fixes that could have caused this regression. Thanks!

Comment 9

[Hema Koka [:hema]]

Triage Decision: Not a release blocker and marking it a polish bug 

David/Russ: Please route to the right team once you take a look

Comment 10

[Russ Nicoletti [:russn]]

There was a change made fairly recently (12/5/14) that could be related (bug 1100842 - Use solid color for dialog background like all other dialogs). I will take a look.

Comment 11

[David Flanagan [:djf]]

This is a very weird bug. That is a tiny bit of the video bleeding through, but it only happens in landscape mode, and only if I rotate 90 degrees counterclockwise to go to landscape. If I turn my phone clockwise into landscape mode, the bleedthrough does not happen then.

Another very weird thing is that this graphical defect does not show up in a screenshot. I take that to mean that there is something very low level going on with video frames being displayed on the HWC and the dialog being rendered by the GPU or something?  I wonder if this is an artifact of our 1.5 device pixel ratio on the Flame. Device pixels and CSS pixels do align perfectly, and in one orientation one device pixel (2/3rds of a CSS pixel) is showing through. Though I'd expect that to happen in portrait mode, since it is the device pixel height of the screen that is not an even multiple of 3...

This is happening in an action dialog created with shared/style/action_menu.css, so we might be able to find a workaround by tweaking the CSS there, but it does seem like there is an underlying graphics bug that should be investigated.  

If I change line 258 of that file from 7rem to 7.1rem, then the bug only appears when I rotate the phone in the other direction! There is no end to this weirdness.

Comment 12

[David Flanagan [:djf]]

This is the code in action_menu.css that controls the gray area around the cancel button at the bottom of the screen:

[role="dialog"][data-type="action"] > menu > button:last-child:before {
  content: '';
  position: fixed;
  width: 100%;
  background-color: #4d4d4d;
  height: 7rem;
  left: 0;
  bottom: 0;
  z-index: -1;
}

If I comment out the background-color line, then the bug goes away, as does the gray background color.
If I do this, then there is a different bug: when I rotate the phone with that line commented out, I see a quick flash of the video as the screen rotates. And interestingly, this flash of video is not just in these 70 pixels at the bottom of the screen. It shows through everywhere in the dialog even though we did not touch those.

Milan: this isn't exactly a reduced test case, but it is easy to reproduce. Is there someone on your team that can investigate?

Russ: if we end up needing to work around this in Gaia, I suspect that we could hide the video when displaying the menu and then show the video again when we dismiss the menu.

Comment 13

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

Does disabling the hardware composer change the behaviour in this bug?

Comment 14

[Russ Nicoletti [:russn]]

FWIW, I played around with the css and found when I change the background property of the options menu to be transparent, the allegedly transparent area disappears (replaced by the actual video image). Also, when I take a screenshot, the "transparent area" does not appear in the screenshot image.

Comment 15

[Russ Nicoletti [:russn]]

Attachment: Photo showing "transparent area"

Comment 16

[Russ Nicoletti [:russn]]

Attachment: screenshot of options menu with "transparent area"

This is a screenshot of the screen from which the photo was taken in the previous attachment.

Comment 17

[Benoit Girard (:BenWa)]

Until I have time looking at this closer it would be useful if someone can rule out the obvious regression candidates:
- Turn off hardware compositor, reboot and retry
- Turn off low resolution drawing, reboot and retry
- Backout (or try a build without) bug 1085223

and/or run a full regression window.

Comment 18

[Benoit Girard (:BenWa)]

Attachment: Display list + layer tree of the bogus frame

Some notes. Still need to analyze the data

Comment 19

[Benoit Girard (:BenWa)]

Here's the profile:

http://people.mozilla.org/~bgirard/cleopatra/#report=c32b909f5878d596e4a8fb754b5387df4c12bd32&filter=[{"type"%3A"RangeSampleFilter","start"%3A48347,"end"%3A48843}]

To view the frame click on 'Display List #21'

Comment 20

[Benoit Girard (:BenWa)]

I suspect it's because of this:
shadow-transform=[ -4.37114e-08 1; -1 -4.37114e-08; 480 0; ]

When we run the opacity code we're not going to be filling the entire pixel because of this offset.

Comment 21

[Benoit Girard (:BenWa)]

Attachment: work arround OR patch

This fixes the problem. I need to think about it some more what we want to do about the case where we're in a integer translated origin in layer space but not in world/screen space.

Comment 22

[Benoit Girard (:BenWa)]

Hey Matt RE ApplyOcclusionCulling, so the problem is the top of our tree (the app container) has a stupid transform:
shadow-transform=[ -4.37114e-08 1; -1 -4.37114e-08; 480 0; ]

The culling code should be able to handle these cases gracefully. What happens here is we can be missing the pixel center in screen space and thus the edges of our region is not opaque even though it -is- opaque in the local layer space. This means the culling can introduce seems at layer edges in spaces with non integer translations.

1) Simple but less ideal fix is my patch above to not attempt these case.
2) We could have a bool in ApplyOcclusionCulling to say that our space origin is not pixel align and then in these case assume our edge wont hit a pixel center and not cull them. In these cases we would do a region shrink by 1 at the edges. This means less bandwidth but risks doing more draw calls as we risk cutting quad into pixel borders (not sure how common that would be).

Comment 23

[Benoit Girard (:BenWa)]

Scratch that, what I wrote doesn't make sense.

This bug only happens when we have an interaction with HWC + Culling + non integer RenderTarget space.

Comment 24

[Benoit Girard (:BenWa)]

Coordinate we're building with HWC. Note that the screen is rotated:

I/Gecko   (25445): Layer composite 0xaf8e2400  <Video>
I/Gecko   (25445): Crop layer 0, 0, 1280, 720
I/Gecko   (25445): Color layer 0, 292, 480, 270
I/Gecko   (25445): Layer composite 0xb17ae400  <Color 1>
I/Gecko   (25445): Crop layer 0, 0, 854, 375
I/Gecko   (25445): Color layer 105, 0, 375, 854
I/Gecko   (25445): Layer composite 0xb098a000  < Color 2>
I/Gecko   (25445): Crop layer 0, 0, 854, 105
I/Gecko   (25445): Color layer 0, 0, 105, 854

Comment 25

[Benoit Girard (:BenWa)]

And here is what I get when I disable culling. Color 1 is smaller since it's culled by Color 2.

I/Gecko   (28118): Layer composite 0xaf3a0c00  <Video>
I/Gecko   (28118): Crop layer 0, 0, 1280, 720
I/Gecko   (28118): Color layer 0, 292, 480, 270
I/Gecko   (28118): Layer composite 0xb0aedc00  <Color 1>
I/Gecko   (28118): Crop layer 0, 0, 854, 480
I/Gecko   (28118): Color layer 0, 0, 480, 854
I/Gecko   (28118): Layer composite 0xb0840800  <Color 2>
I/Gecko   (28118): Crop layer 0, 0, 854, 105
I/Gecko   (28118): Color layer 0, 0, 105, 854

Sushil the dimensions we're sending to HWC look correct but the ones in Comment 23 have a pixel gap. Could this be a HWC bug?

Comment 26

[BMO Automation]

Firefox OS is not being worked on