Closed Bug 726766 Opened 12 years ago Closed 1 year ago

Boxes whose perspective puts them partly behind the viewer don't render as expected (large Z coordinate causes flipping/reflection instead of disappearance)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ayg, Unassigned)

References

Details

Test-case:

data:text/html,<!doctype html>
<div style="-moz-perspective:35px;width:100px">
<div style="background:blue;height:50px;
-moz-transform:rotatey(-45deg)">

Nothing renders.  If you change -45deg to -44deg, you get a box whose right edge is enormous, scrolling well off the screen.  This matches Chrome 18 dev.  On the other hand, IE10 Developer Preview lets you set whatever angle you want -- the box is still visible at -80deg, just progressively bigger.  At -89.9deg, it pretty much fills the whole right of the screen out to a very large distance.  IE's behavior seems correct.

Another test-case:

data:text/html,<!doctype html>
<div style="-moz-perspective:35px;width:100px">
<div style="background:blue;height:50px;
border-left:10px solid yellow;
-moz-transform:translateZ(40px)">

The border is flipped to the right side.  I understand why this happens, but it's going to be very weird to authors.  IE and Chrome make it disappear, which is more expected.


See spec bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15605#c6  The issue here is that at -45deg or less, some points in the box get mapped to points at infinity, of the form (x, y, z, 0); and some have their fourth coordinate negative.  It seems to me that the expected behavior is:

1) Any points with fourth coordinate negative are not drawn.  IE and WebKit seem to do this.  Gecko seems to mirror the points, which mathematically makes sense but isn't what anyone would reasonably expect.

2) If any point has fourth coordinate zero, draw a ray toward infinity in that direction.  What size the box should be for the purposes of scrolling, etc. is an exercise for the reader.  IE does something like this -- I didn't test what size it gives the box.
Thinking about it a bit more:

* If w is positive for all four corners of the box, behavior is obvious.
* If it's zero or negative for all four corners, render nothing.
* If it's positive for some corners and nonpositive for others, any parts with negative w should be cut out, which in general will leave you with a polygon with three to five vertices.  Then there will be two vertices of this polygon with the form (x, y, z, 0).  These can be mapped to (n*x, n*y, n*z, 1), where n is such that n*x or n*y is "large enough" that it's close enough to infinite for our purposes.  Then it should look as expected.

I have no idea if that makes sense in terms of code, but it makes sense to me geometrically.  IE seems to do something similar-ish.
Summary: Boxes whose perspective puts them partly behind the viewer don't render as expected → Boxes whose perspective puts them partly behind the viewer don't render as expected (large Z coordinate causes flipping/reflection instead of disappearance)
Testcase joined to the duplicate bug:
https://bugzilla.mozilla.org/attachment.cgi?id=610557
Blocks: 745523
This appears to only happen with BasicLayers, and is likely a bug / design decision with the way that pixman handles 3x3 matrix transformations.

I don't think we necessarily need to block un-prefixing on this rendering bug.
What's the behavior with non-BasicLayers setups?  Browsers are very inconsistent here.  I think Dirk Schulze and I currently agree that the best idea is just not to render if any part of the box is given z greater than the perspective -- although it's not always totally obvious what that means (box-shadow, root element, . . .).  Flipping things is definitely a bug, presumably resulting from treating negative fourth coordinates the same as positive.

Since there's no interop anyway, and browsers are inconsistent as-is, I think it would make sense to not block unprefixing on this.  It would be good if we could fix it, though.
The behavior is entirely dependent on what the drawing backend is doing, so I'd expect things to be fairly consistent between browsers running with GPU acceleration.

On OSX, with OpenGL layers the original two examples give me:

Large blue box, extending off the right side of the page

Nothing

Which matches the expectations I believe.

I think we should probably check that the majority of the 3d drawing API's (OGL, D3D9/10 etc) are doing the same thing here, and spec on that behaviour. Trying to do something different will probably be painful and confusing.

As for fixing this bug, splitting planes won't be great, but should be possible.

With the IE10 implementation, do you get horizontal scroll bars with the first test case? I'm wondering if our overflow calculations need to take this into account too.
(In reply to Matt Woodrow (:mattwoodrow) from comment #6)
> I think we should probably check that the majority of the 3d drawing API's
> (OGL, D3D9/10 etc) are doing the same thing here, and spec on that
> behaviour. Trying to do something different will probably be painful and
> confusing.

I think that makes lots of sense, but I don't know the first thing about 3D drawing APIs, so I'm not a good person to do the checking.

> With the IE10 implementation, do you get horizontal scroll bars with the
> first test case? I'm wondering if our overflow calculations need to take
> this into account too.

IIRC, yes.
I wonder if this is part of the same issue. here 
https://webcompat.com/issues/3406
https://webcompat.com/issues/3273

If not I'm happy to open a new bug for it.
There's an explanation of the potential issue on 
https://webcompat.com/issues/3406#issuecomment-253405002

It combines visibility, animation and perspective.
Flags: needinfo?(dbaron)
Severity: minor → S4

All the test cases in comment 0 look the same in Chromium and Firefox now.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(dbaron)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.