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.
ok, make sense
(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.
Link of Testcase of duped Bug 691861: https://bugzilla.mozilla.org/attachment.cgi?id=564621
[Triage Comment] The bug this bug blocks is marked as resolved, so we didn't block on this. Minusing for tracking.
(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.
sorry, s/(new bug)/(new feature)/
(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.
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 (126.96.36.199) -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/
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.
The test case url can no longer be reached. If you attach a simple test case, that the first step to any resolution here.
There is a very representative and easy example here: http://jsfiddle.net/yNfQX/21/
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.
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.
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.
Miko, will you also recover improving layer sorting as what I have done in bug 1208646?
sorry, I mean "cover".
(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.
Miko, do you still work on this bug?
(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.
Adding DevAdvocacy keyword, as this is showing up in places like https://css-tricks.com/things-watch-working-css-3d/
Created attachment 8806839 [details] cssplanesplittingscreenshot.PNG Comparison screenshot of article from comment 28 in both Firefox and Chrome.
Too late for firefox 52, mass-wontfix.
Miko: can we now say this bug is Fixed?
(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.
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.