Skip to content

Backface visibility is not propagated properly #3114

Closed
@kvark

Description

@kvark
Member

Activity

self-assigned this
on Sep 24, 2018
Gankra

Gankra commented on Sep 24, 2018

@Gankra
Contributor

test-case demonstrating this is both Z-fighting and one element (the .back::before psuedo-element's background) getting which side its "back" is backwards. backface-visibility seems to be propagating properly, afaict.

https://bugzilla.mozilla.org/show_bug.cgi?id=1454706#c14

kvark

kvark commented on Sep 25, 2018

@kvark
MemberAuthor

Thanks for the test case @gankro !

I'm observing the world transformations for both red and blue planes to be the same, which is unexpected (given that one is supposed to be flipped):

// spatial node index 12
[1.0252677, 0.029520191, -0.17364818, 0.0001736482, 0.0, 1.0, 0.0, 0.0, -0.05581203, -0.16741732, 0.9848077, -0.0009848077, 156.10492, 86.78599, 13.023613, 0.9869764]
// spatial node index 15
[1.0252677, 0.029520191, -0.17364818, 0.0001736482, 0.0, 1.0, 0.0, 0.0, -0.05581203, -0.16741732, 0.9848077, -0.0009848077, 186.86295, 87.6716, 7.814169, 0.99218583]

The indices were obtained with the help of chasing + capturing infrastructures.

So WR thinks both items are facing the same way, mistakenly.

kvark

kvark commented on Sep 25, 2018

@kvark
MemberAuthor

@gankro the title needs to be changed, but I've yet to find what to change it to ;)

I actually got confused about that testcase now. .back::before ends up with the same world transformation (as the red rectangle) appears to be expected by the testcase, since it's flipped but the parent (with class "bf-invisible container-inner back") is also flipped. So I'm not sure what the desired outcome should be.

Do you think that it should function as if the parent establishes the stacking context, and since it has the backface visibility disabled, all children should be invisible if the spatial node (corresponding to this context, not the children) is turning the back? This is obviously different from the current logic, where we just propagate the flag and check for backface visibility at the primitive level (as opposed to the stacking context level).

Gankra

Gankra commented on Sep 26, 2018

@Gankra
Contributor

I don't think foo and foo::before are supposed to have a parent-child relationship? ::before is literally before.

mstange

mstange commented on Sep 26, 2018

@mstange
Contributor

No it's not - it's a really bad name for what it is. foo::before is a child of foo, just before all the other children of foo.

kvark

kvark commented on Sep 26, 2018

@kvark
MemberAuthor

I'm inspecting the page and seeing the following hierarchy:
badge-hierarchy

Gankra

Gankra commented on Sep 26, 2018

@Gankra
Contributor

Ok after some discussion with mstange and some experimentation with gecko/chrome, it looks like this is incorrect backface-visibility handling. The blue is indeed double rotated, and therefore facing the same way as the red.

The mistake is one of two things, which we still need to work out:

  • we're incorrectly propagating backface: hidden down to the blue rect
  • we're incorrectly applying backface:hidden to the blue rect

The distinction being whether the blue rect should be considered rotated and actually rendered in 3d, or just rotated and 2d-projected into its parent. In the latter case the blue rect's backface doesn't actually matter, but rather only the backface of the parent does. My hypothesis is that the latter is occuring, because otherwise the blue rect would be "always visible" and would therefore always draw on top of the red one (as it does in the backface:visible example).

Gankra

Gankra commented on Sep 26, 2018

@Gankra
Contributor

(note the red and blue rects are slightly different because the blue rect has a transform directly applied to it, and the red one doesn't)

changed the title [-]Backface visibility is not propagated properly[/-] [+][WIP] Backface visibility is not propagated properly[/+] on Sep 26, 2018
changed the title [-][WIP] Backface visibility is not propagated properly[/-] [+]Backface visibility is not propagated properly[/+] on Sep 26, 2018
added a commit that references this issue on Oct 22, 2018

Auto merge of #3131 - kvark:backface, r=gw3583

838ce47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @kvark@mstange@Gankra

      Issue actions

        Backface visibility is not propagated properly · Issue #3114 · servo/webrender