966527 - CSS-3d-transformed (perspective) elements missing

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Florian Bender]

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

1. Goto URL
2. see the pilot dying because the fighter misses a few walls that Firefox ripped out :(


This is different from Bug 966519 because this is not a regression, at least that I know of (did some preliminary regression testing, 2012-07-09 is still bad). 

Chrome let's the pilot live. MozImperium much?

Note this may have a TE component but AFAICS the TRIDIV demo/lib does not produce engine-specific code (at least not exclusively). Though I may be mistaken and/or the code uses outdated spec behaviour …

Comment 1

[Florian Bender]

concluding my graphics-bug-hunting for today …


Oh, disabling HW accel does not change the situation here. FWIW: 

Device ID	0x 166
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Vendor ID	0x8086
WebGL Renderer	Intel Inc. -- Intel HD Graphics 4000 OpenGL Engine
windowLayerManagerRemote	true
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

Comment 2

[Florian Bender]

One more thing: On several slides in http://rupl.github.io/unfold/ elements disappear and reappear during animation and/or before the animation started resp. after it ended: e.g. the solar system, the (floor) tiles (some tiles are also :hover activated, so you can move the mouse around to see this bug), etc. On the slide with the (floor) tiles you can see that some 3d-transformed elements are half-transparent while they don't have any opacity change commanded by the CSS – don't know if this is the same or a different issue; shall I file a new bug?


Bug 966519 covers the issue that made the situation far worse than it used to be.

Comment 3

[Nicolas Silva [:nical]]

Could this be the same problem as bug 936043?

Comment 4

[Florian Bender]

Tentatively adding as "see also" …

Comment 5

[Matt Woodrow (:mattwoodrow)]

I suspect this is also a regression from bug 947467.

Comment 6

[Florian Bender]

This bug is not about the regression, the issue has always been there (at least since 2012). I "moved" the dependancy to Bug 966519.

Comment 7

[Florian Bender]

There's a similar issue in http://rupl.github.io/unfold/ – see the slide with the tiles (after the "solar system" slide): It's not only missing elements but elements are also (partially) transparent when they shoudn't be. 

See also Bug 936043 which exhibits the same behaviour (the planets do) and Bug 936376 (having z-ordering issues like some elements in the supplied URL).

Comment 8

[andrew.steadman]

I'm experiencing similar issues, but i'm not sure if its the same bug. Often, at certain rotation angles, some or all of a transformed element disappear. For me, this seems to happen when at least one corner has a z-component (when transformed) greater than or equal to the perspective of the parent (this may not be the same as above, i'm not sure).

Demonstration URL: http://jsbin.com/yopejipi/1 , hover over the red rectangle to change a rotation angle by 0.1 degrees. For me, almost the entire rectangle disappears. On other browsers (for example, IE 11), it works fine. Given the small change in angle, there should be no discernible difference between the normal and hover styles.

Based on my math, and including the border width, the bottom right corner ([102,102,0,1]) gets mapped (post perspective calculation) to [244.32,95.84,120.12,-0.001] ie: it has a small negative w value. According to http://dev.w3.org/csswg/css-transforms/#processing-of-perspective-transformed-boxes that corner should then be removed and a new polygon created with extra nodes at the points where w=0. Visually, to me, it looks like the wrong corner is removed? Certainly part of the rectangle is still visible, but not the majority of it. That's my assumption anyway.

I've tested on windows. Present in Aurora 29.0a2 (2014-03-17) and Firefox 27.0.1.

Comment 9

[Florian Bender]

(In reply to andrew.steadman from comment #8)
> Often, at certain rotation angles, some or all of a transformed element
> disappear. For me, this seems to happen when at least one corner has a
> z-component (when transformed) greater than or equal to the perspective of
> the parent (this may not be the same as above, i'm not sure).

Hmm interesting. That needs to be investigated. I'll revisit this in May if nobody else checks this in the meantime. Thanks for the hint!

> Demonstration URL: http://jsbin.com/yopejipi/1 , hover over the red
> rectangle to change a rotation angle by 0.1 degrees. For me, almost the
> entire rectangle disappears. On other browsers (for example, IE 11), it
> works fine. Given the small change in angle, there should be no discernible
> difference between the normal and hover styles.

For me, it's flickering on mouse hover. Sometimes, it's visible when the mouse is steady, sometimes it's not (especially if I move my mouse over the top parts). When it's not visible, there's only a rather small red triangle in the top right corner.

Either way, can you please file a new bug adding this one as "see also"? This may have a similar root cause but IMHO should be tracked separately.

Comment 10

[andrew.steadman]

I've filled a separate bug report for my bug at https://bugzilla.mozilla.org/show_bug.cgi?id=987108 

The flickering is caused by the bounds being calculated incorrectly and the ":hover" styling no longer applying post transformation. It appears to flicker less on the left hand side of the rectangle.

Comment 11

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 12

[Gregory Pappas [:gregp]]

Fixed by WebRender? Do you still see problems in this demo on your machine?

Comment 13

[Florian Bender]

Hmm I don't have the reference machine any more. The x-wing now seems to look the same in Fx 100 and Safari 15 but is still missing elements. Not sure this is an issue of the demo or the rendering engines, though.

I'd say this can be closed but I cannot check parity against Chrome at the moment.

Comment 14

[Gregory Pappas [:gregp]]

(In reply to Florian Bender from comment #13)

I'd say this can be closed but I cannot check parity against Chrome at the moment.

I don't see any missing elements when looking at Chromium and Firefox side by side (Linux, Wayland). Perhaps you're hitting a bug in OS compositor integration?

Glenn, are you able to check this out or bounce it to the right person? Thanks!

Comment 15

[Glenn Watson [:gw]]

Looks the same in Chromium and Firefox to me too. It shouldn't be a OS compositor difference, as 3d CSS elements are drawn in to normal 2D surfaces by the same code path in WR and don't interact with the platform compositor.