Intersecting planes are not z-ordered properly (need to implement plane splitting for CSS 3d transforms)

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
6 years ago
5 days ago

People

(Reporter: romaxa, Assigned: miko)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {DevAdvocacy, testcase})

Trunk
DevAdvocacy, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox10-, firefox50 affected, firefox51 affected, firefox52 wontfix, firefox53 affected)

Details

(Whiteboard: [webvr][css-vr][parity-Chrome][parity-Edge], URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Seems like z-ordering for intersecting planes not working properly
also I see this in debug build log
###!!! ASSERTION: Child transform frame must preserve 3d!: 'childFrame->Preserves3D()', file layout/generic/nsFrame.cpp, line 1484
The assertion is the same as mentioned in bug 689501 and appears to be invalid in both cases.

Sorting intersecting (or cycled) layers is a known problem that we don't handle at all currently.

Chrome has the same behaviour as us for this demo, they sort intersecting planes arbitrarily. They appear to sort these two planes in a different order for this demo, which looks slightly better.
Safari actually handles this correctly, using CoreAnimation, which apparently splits intersecting planes into multiple pieces so that they can be sorted correctly.

I'd quite like us to have plane splitting (or depth buffering) to solve this, but it's not an easy problem. I don't think we should block enabling 3d transforms on this, since the spec doesn't require any sort of specific sort handling.
(Reporter)

Comment 2

6 years ago
ok, make sense
Duplicate of this bug: 691861
(In reply to Matt Woodrow (:mattwoodrow) from comment #1)
> I'd quite like us to have plane splitting (or depth buffering) to solve
> this, but it's not an easy problem. I don't think we should block enabling
> 3d transforms on this, since the spec doesn't require any sort of specific
> sort handling.

I wouldn't make that decision based on what the spec requires (especially this particular, not very thorough, spec).  I think the relevant criterion should be whether it's going to be a significant problem for authors.  It seems to me like it might be, but I'm far from the right person to judge that.
tracking-firefox10: --- → ?
Link of Testcase of duped Bug 691861:
https://bugzilla.mozilla.org/attachment.cgi?id=564621
Keywords: testcase
OS: Linux → All

Comment 6

6 years ago
[Triage Comment]
The bug this bug blocks is marked as resolved, so we didn't block on this. Minusing for tracking.
tracking-firefox10: ? → -
(In reply to Alex Keybl [:akeybl] from comment #6)
> [Triage Comment]
> The bug this bug blocks is marked as resolved, so we didn't block on this.
> Minusing for tracking.

That doesn't make any sense.  We need to either explicitly decide that it's ok to ship 3D transforms (new bug) with this bug or we need to fix this bug for 10.
tracking-firefox10: - → ?
sorry, s/(new bug)/(new feature)/

Comment 9

6 years ago
(In reply to David Baron [:dbaron] from comment #7)
> (In reply to Alex Keybl [:akeybl] from comment #6)
> > [Triage Comment]
> > The bug this bug blocks is marked as resolved, so we didn't block on this.
> > Minusing for tracking.
> 
> That doesn't make any sense.  We need to either explicitly decide that it's
> ok to ship 3D transforms (new bug) with this bug or we need to fix this bug
> for 10.

You're right - I thought 505115 already landed with FF8 but was mistaken.

Who can weigh in on whether 505115 can be shipped without this bug fixed?
(In reply to Alex Keybl [:akeybl] from comment #9)
> Who can weigh in on whether 505115 can be shipped without this bug fixed?

mattwoodrow, roc
Safari and Chrome both shipped releases with this problem. I think we can too.

Updated

6 years ago
tracking-firefox10: ? → -

Comment 12

5 years ago
Safari & Mobile Safari no longer have this problem. The problem still exists in Chrome and Firefox.

Broken: Firefox 14.0a1 (2012-04-12) -Win7
Broken: Chrome 20.0.1096.1 -Win7
Fixed : Safari 5.1.5 (75.34.55.3) -Win7
Fixed : Mobile Safari (last updated over a month ago) -iOs

Link to test-case and screen-grabs:
http://f1lt3r.com/code/3d-css-transforms-intersecting-planes-not-clipping/

Updated

5 years ago
Blocks: 745523

Updated

4 years ago
Blocks: 904304
Duplicate of this bug: 937137

Comment 14

3 years ago
This bug is really nasty. It forbids any polygon intersection in CSS 3D engines.
So it is impossible to make something appears through a plane for example.
Sadly, this is a really old bug and nobody seems to take care even if css3D sites are expanding a lot being the only way to be 3D compatible to safari devices.

Comment 15

3 years ago
The test case url can no longer be reached. If you attach a simple test case, that the first step to any resolution here.

Comment 16

3 years ago
There is a very representative and easy example here:
http://jsfiddle.net/yNfQX/21/

Comment 17

3 years ago
The URL at the top of the page still works and still shows the issue.

This one does too

http://greggman.com/downloads/examples/intersecting-elements-3d-css.html

Note that it doesn't work in Chrome either. Only Safari is subdividing the polygons to make things sort correctly. A zbuffer will fix the example at the top of the page but only subdividing will fix the 2nd URL.

Comment 18

3 years ago
I don't know if it's appropriate to post here but this is the chromium issue # AFAICT

https://code.google.com/p/chromium/issues/detail?id=230833
http://en.wikipedia.org/wiki/Newell%27s_algorithm is cited by http://dev.w3.org/csswg/css-transforms/#3d-transform-rendering as the way to handle this.
(Reporter)

Updated

3 years ago
Hardware: x86 → All
Summary: Intersecting planes are not z-ordered properly → Intersecting planes are not z-ordered properly (need to implement plane splitting for CSS 3d transforms)

Updated

3 years ago
Duplicate of this bug: 1106603
Assignee: nobody → kgilbert
Whiteboard: [webvr]
Depends on: 1097464
Before plane splitting can be implemented, the sort order must be corrected as it is incorrect even in cases where the planes do not intersect.

Bug 1175311 tracks the sorting fix, which is a prerequisite of this bug.
Depends on: 1175311
See Also: → bug 932488

Updated

a year ago
Whiteboard: [webvr] → [webvr][css-vr]
Depends on: 1274673
No longer depends on: 1175311, 1097464
Depends on: 1175311, 1097464

Updated

a year ago
Blocks: 1225654
(Assignee)

Updated

11 months ago
Assignee: kgilbert → mikokm
Status: NEW → ASSIGNED

Comment 22

11 months ago
Miko, will you also recover improving layer sorting as what I have done in bug 1208646?

Comment 23

11 months ago
sorry, I mean "cover".
(Assignee)

Comment 24

11 months ago
(In reply to Thinker Li [:sinker] from comment #22)
> Miko, will you also cover improving layer sorting as what I have done in
> bug 1208646?
The ultimate goal is to use binary space partitioning for layer sorting as described in bug 1274673.
(Assignee)

Updated

11 months ago
Depends on: 1285380
(Assignee)

Updated

11 months ago
Depends on: 1286716

Comment 25

8 months ago
Miko, do you still work on this bug?

Updated

8 months ago
Whiteboard: [webvr][css-vr] → [webvr][css-vr][parity-Chrome][parity-Edge]
(Assignee)

Comment 26

8 months ago
(In reply to Thinker Li [:sinker] PTO during Sep 22 ~ 30 from comment #25)
> Miko, do you still work on this bug?

I'm working on the OpenGL portion of this.
Duplicate of this bug: 1306748
Adding DevAdvocacy keyword, as this is showing up in places like https://css-tricks.com/things-watch-working-css-3d/
Keywords: DevAdvocacy
Created attachment 8806839 [details]
cssplanesplittingscreenshot.PNG

Comparison screenshot of article from comment 28 in both Firefox and Chrome.

Updated

7 months ago
Duplicate of this bug: 1315959
(Assignee)

Updated

6 months ago
Duplicate of this bug: 1319683
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
Depends on: 1323791
(Assignee)

Updated

4 months ago
Depends on: 1332070

Updated

2 months ago
Duplicate of this bug: 1350804
(Assignee)

Updated

2 months ago
Depends on: 1353430
Too late for firefox 52, mass-wontfix.
status-firefox52: affected → wontfix
Miko: can we now say this bug is Fixed?
(Assignee)

Comment 35

6 days ago
(In reply to Jet Villegas (:jet) from comment #34)
> Miko: can we now say this bug is Fixed?

I would say so. The only open thing currently is the support for intersections in BasicLayers (bug 1353430), but this is something that the other browsers are not supporting yet either.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 days ago
Resolution: --- → FIXED
Confirmed the example in comment #28 is working correctly now in Nightly. Thanks y'all.
(In reply to Miko Mynttinen [:miko] from comment #35)
> I would say so. The only open thing currently is the support for
> intersections in BasicLayers (bug 1353430), but this is something that the
> other browsers are not supporting yet either.

It's pretty unusual to have such substantial rendering differences between BasicLayers and the other layers implementations, though.  They're supposed to be faster, not different.
You need to log in before you can comment on or make changes to this bug.