Closed Bug 1655732 Opened 1 year ago Closed 1 year ago

White flicker on CSS transitions while closing selections with WebRender

Categories

(Core :: Graphics: WebRender, defect, P3)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
83 Branch
Tracking Status
firefox-esr68 --- disabled
firefox-esr78 --- disabled
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- verified

People

(Reporter: atrif, Assigned: kvark)

References

(Blocks 1 open bug, )

Details

(Keywords: correctness, regression)

Attachments

(4 files)

Attached image css_transition.gif

Affected versions

  • 81.0a1 (20200727203201)
  • 80.0b1 (20200727193419)
  • 79.0 (20200720193547)
  • 78.1.0esr (20200722151235)

Affected platforms

  • Windows 10x64
  • macOs 10.12
  • Ubuntu 18.04

Preconditions

  • Make sure gfx.webrender.all is set to true.

Steps to reproduce

  1. Open Firefox and go to https://bug1358102.bmoattachments.org/attachment.cgi?id=8867531.
  2. Change from Layouts to Sliders and observe the behavior.

Expected result

  • No flickering occurs.

Actual result

  • White flickering while transitioning.

Regression range

  • Reproducible with Firefox 74.0a1 (20200206214720). I will search for one ASAP.

Notes

  • Attached a screen recording.
Has Regression Range: --- → yes
Has STR: --- → yes
Summary: White flicker on https://bug1358102.bmoattachments.org/attachment.cgi?id=8867531 while closing selections with WebRender → White flicker on CS transitions while closing selections with WebRender
Has Regression Range: yes → no
Summary: White flicker on CS transitions while closing selections with WebRender → White flicker on CSS transitions while closing selections with WebRender

2018-08-01 (Fx63) seems completely fine. Then we got two bugs and one was fixed.


good: 2018-08-01 (Fx63) seems completely fine.
bad: 2018-10-01 (Fx64): Submenu was buggy (misplaced text and cut-off elements), but sub-submenu did not have white flickering.
mozregression --good 2018-08-01 --bad 2018-10-01 --pref gfx.webrender.all:true -a https://bug1358102.bmoattachments.org/attachment.cgi?id=8867531

5:25.67 INFO: Last good revision: fea371cafd2c73be689184ca6670e33c3fd1636c (2018-09-10)
5:25.67 INFO: First bad revision: 1169e8a4ca2b7f3cbffdaf70f6d18a5142ed32d7 (2018-09-11)
5:25.67 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fea371cafd2c73be689184ca6670e33c3fd1636c&tochange=1169e8a4ca2b7f3cbffdaf70f6d18a5142ed32d7


This bug:
good: above bad
bad: 2018-12-01 (Fx65): Submenu was buggy (misplaced text and cut-off elements) and sub-submenu did have white flickering (comment 0).
mozregression --good 2018-08-01 --bad 2018-12-01 --pref gfx.webrender.all:true -a https://bug1358102.bmoattachments.org/attachment.cgi?id=8867531

5:56.27 INFO: Last good revision: 12cc80a0e9968ade961879ee07effb815da691f0 (2018-11-08)
5:56.27 INFO: First bad revision: d3d642b624886729636c3690a806f38b4d737731 (2018-11-09)
5:56.27 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=12cc80a0e9968ade961879ee07effb815da691f0&tochange=d3d642b624886729636c3690a806f38b4d737731


bad: above bad
good: 2019-05-01 looks like today: Submenu is no longer buggy, but sub-submenu has white flickering (comment 0).
mozregression --find-fix --bad 2019-02-01 --good 2019-05-01 --pref gfx.webrender.all:true -a https://bug1358102.bmoattachments.org/attachment.cgi?id=8867531

4:02.35 INFO: First good revision: 47048ef82b50e3130220d86b09f5addf0b58906e (2019-02-12)
4:02.35 INFO: Last bad revision: b9187fa10f13a7b84f21c973d33d2fdb0f37bbb0 (2019-02-11)
4:02.35 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9187fa10f13a7b84f21c973d33d2fdb0f37bbb0&tochange=47048ef82b50e3130220d86b09f5addf0b58906e

Keywords: correctness
Has Regression Range: no → yes
Flags: needinfo?(gwatson)

I can repro this locally, but probably won't have a chance to investigate this week.

Dzmitry, would you have time this week to take a look? Otherwise, I could investigate next week.

Flags: needinfo?(gwatson) → needinfo?(dmalyshau)
Severity: -- → S3
Priority: -- → P3

I haven't got time to look at it this week, will keep it on the radar for the next one.
From the gifs, it looks to be related to 3D and plane splitting.

Assignee: nobody → dmalyshau
Flags: needinfo?(dmalyshau)
Attached image wr-backface-change.png

Interestingly, the behavior has changed now, and it looks like this.
The only related change I know to this that has come in recently is of bug 1657690

Confirmed, bug 1657690 comment 4 changed the behavior from comment 0 into comment 4.

See Also: → 1659418
Attached file spatial-1-0.tree

Spatial tree of a WR capture. The relative transform from node 7 to node 2 shows up to be front-face visible, were we are expecting it to be back face.

When we are looking at a transform of an element relative to the surface
it's rendered into, we used to only consider the final transformation
when determining back-face visibility.
However, in case there are any Flat reference frames on the way,
the transformation is flattened. We should be checking for back-face
visibility on each such step.

This doc was helpful, although it doesn't have all the answers:
https://docs.google.com/document/d/1yb4a_uhTG3KmcbGPta4B9p67v1HO_qY8ZMk-otGOwTc/

Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3013857e5351
Fix backface-visibility checks with regards to intermediate flattening. r=gw
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Verified with Firefox 83.0a1 (20201012152719) with WebRender on Windows 10x64, macOS 10.12 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.