1073056 - 3D rotation using CSS 3D styles is broken, Black area appears when HWA enabled

Status: RESOLVED DUPLICATE of bug 1035611

(Core :: Layout, defect)

Description

[Alice0775 White]

Attachment: screenshot

[Tracking Requested - why for this release]: Regression

+++ This bug was initially created as a clone of Bug #1072898 +++

Steps to reproduce:
1. Make sure HWA enabled. 
2. Open http://walk-inside.com/sample1/?format=0&size=2

3. Mouse down on image
4. Dragging mouse pointer a little distance(50-100px). 
5. Mouse up and move mouse pointer around browser
   --- Observe images
6. Repeats the step 3, 4, 5, 6 if necessary

Actual results:
Black area appears 

Expected results:
Panoramic image should display properly

Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/68e96eb00d3e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140725154406
Bad:
https://hg.mozilla.org/mozilla-central/rev/e07264876182
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140725160007
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68e96eb00d3e&tochange=e07264876182


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a6758d669350
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140725014111
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/780188e2dab7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140725022609
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a6758d669350&tochange=780188e2dab7

Regressed by: 
780188e2dab7	Nicolas Silva — Bug 1042052 - Add TextureClient::CreateSimilar and have component alpha buffer be of the same type. r=sotaro

Comment 1

[alex]

Steps to reproduce:
1. Make sure HWA is *disabled*!

Comment 2

[Alice0775 White]

(In reply to alex from comment #1)
> Steps to reproduce:
> 1. Make sure HWA is *disabled*!

No, 
This bug is in case of HWA ENABLE.

Comment 3

[Alice0775 White]

Steps to reproduce:
1. Make sure HWA enabled.  HWA enabled, not disabled
2. Open http://walk-inside.com/sample1/?format=0&size=2

3. Mouse down on image
4. Dragging mouse pointer a little distance(50-100px). 
5. Mouse up and move mouse pointer around browser
   --- Observe images
6. Repeats the step 3, 4, 5, 6 if necessary

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

Milan - Can you please have someone look at this reported regression in 34?

Comment 5

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

:nical, can you reproduce this (see comment 3)?  If so, let me know if you're the right person to take a look at this, and if not, just unassign yourself and I'll find somebody else.

Comment 6

[Nicolas Silva [:nical]]

I can reproduce this, I'll take a look.

Comment 7

[Nicolas Silva [:nical]]

Turns out that at certain angles we are destroying the ImageLayer that contains a face of the "cube map" that is used in this website. So the the problem is in layout (I suppose somewhere in FrameLayerBuilder) rather than gfx and I am not the right person to investigate it.

Comment 8

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

Thanks for investigating this.  Passing to Layout; Matt's name was mentioned, so needinfo on him first :)

Comment 9

[Matt Woodrow (:mattwoodrow)]

Alice, are you sure about the regression range for this bug?

I can still reproduce this locally with the blamed changeset backed out.

Comment 10

[Alice0775 White]

(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> Alice, are you sure about the regression range for this bug?
> 
> I can still reproduce this locally with the blamed changeset backed out.

Yes, I am sure.

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

Matt - Assigning to you as it looks like you're taking this bug.

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

Matt - Are you still able to work on this for 34?

Comment 13

[Matt Woodrow (:mattwoodrow)]

I'm not sure I'll be able to get to this in time sorry.

I tried doing local builds and couldn't reproduce the issue with builds before/after the regression range. I can reproduce it with a tip build though.

Comment 14

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

I wouldn't be surprised if this was the same as bug 1085187...

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Milan Sreckovic [:milan] from comment #14)
> I wouldn't be surprised if this was the same as bug 1085187...

Not that this is necessarily correct but bug 1085187 says that 34 is unaffected and this bug is marked as 34 affected.

Matt - Given that you can reproduce the issue with a tip build, can you try to investigate the source in time for beta11 (goes to build on Thu, Nov 20)?

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

This is now wontfix for 34. 

Matt - Can you pickup this investigation so that this can potentially be fixed early in the 35 beta cycle?

Comment 17

[Matt Woodrow (:mattwoodrow)]

I spent some time looking at this today, it very much looks like the same as bug 1072898, though with slightly different symptoms. I can reproduce it on OSX too.

All the layers are there, but visible regions look pretty bogus.

I'll see if I can find someone that understands the math behind that bug a little better next week, because I don't have any leads yet.

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

We've only got one beta left on Mon Dec 29th, too late for speculative fixes.  Continuing to track for 36 in the hopes that this gets prioritized after the holidays.

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Matt, have you been able to find someone to help you? Thanks

Comment 20

[Jet Villegas (inactive)]

Kip: can you take a look here?

Comment 21

[:kip (Kearwood Gilbert)]

I have reproduced on OSX.  I'll take this and investigate further.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Kip, any news on this? We built beta 6 yesterday and we are getting closer to the release now. Thanks

Comment 23

[:kip (Kearwood Gilbert)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #22)
> Kip, any news on this? We built beta 6 yesterday and we are getting closer
> to the release now. Thanks
I expect to be back on this early next week, then it will be my priority to fix.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

Kip, are you still planning to fix that for 36? Thanks

Comment 25

[:kip (Kearwood Gilbert)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #24)
> Kip, are you still planning to fix that for 36? Thanks
I am back on this issue now, as my priority.  I expect to have it fixed shortly, aiming to get it in for 36.

Comment 26

[:kip (Kearwood Gilbert)]

Enabling the CULLING_LOG define in ContainerLayerComposite.cpp reveals the layers culled:

"CULLING: Sublayer 0x.... has no effective visible region"

Disabling the "continue" statement below that logging line in the ContainerPrepare (ContainerLayerComposite.cpp) function eliminates the erroneous black regions in the screenshot.

For the layers that are being incorrectly culled, both mShadowVisibleRegion and mVisibleRegion have all members zero'ed out.

Continuing to investigate...

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Looks like we won't have a fix for 36 ready. However, we will probably take a patch for 37 if it arrives soon.

Comment 28

[:kip (Kearwood Gilbert)]

The incorrect bounding box calculation that causes incorrect culling appears to be related to Bug 1035611.  Increasing the magic number in ComputePerspectivePlaneIntercept from 0.00001f to 0.01f reduces the range of the angles that cause the incorrect culling, while decreasing it to 0.00000001f greatly increases the range of angles that cause the incorrect culling.

I will attempt to update the bounding box calculation code to correctly handle w=0 coordinates so that the work-around in ComputePerspectivePlaneIntercept will not be required.

Comment 29

[Lawrence Mandel [:lmandel] (use needinfo)]

Kip - There are only 3 Betas left in the 37 cycle. Do you have time to work on this bug this week in order for us to consider taking a fix in 37?

Comment 30

[:kip (Kearwood Gilbert)]

I am back on this bug again now and it is my priority item for this week.

I have confirmed that the culling failure will be corrected by fixing Bug 1035611.  I am attempting to fix that one, and will re-test this to confirm it was corrected.

Comment 31

[:kip (Kearwood Gilbert)]

I have found a solution to this, which also corrects Bug 1035611.  Please see Bug 1035611 Comment 2 for details.

Comment 32

[:kip (Kearwood Gilbert)]

I have added a patch to Bug 1035611 which corrects this issue.

Comment 33

[Lawrence Mandel [:lmandel] (use needinfo)]

Bug 1035611 is not going to ship in 37 but should make 38.

Comment 34

[:kip (Kearwood Gilbert)]

The test added to Bug 1035611 covers the issue that causes the incorrect rendering in this bug.  This is in inbound currently.

Comment 35

[:kip (Kearwood Gilbert)]

I have confirmed Bug 1035611 to be the same issue, as its patch fixes the issues described on the site referenced in the user story.