Closed Bug 1698009 Opened 7 months ago Closed 6 months ago

sw-wr: recorded Zoom video has a white line behind the video

Categories

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

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- fixed

People

(Reporter: cpeterson, Assigned: lsalzman)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached image Zoom_screenshot.jpg

Steps to reproduce

  1. Enable gfx.webrender.software and restart Firefox.
  2. Load recorded Zoom video https://mozilla.zoom.us/rec/play/x6QDxiEIXCNUCHkKSVqEEG6nGFYxjKAwCLZ3OooCAV4rv1SVpVIp8lpdHbMzQd8EBh0TSzHNSbv7p2xM.RQZiLaVWCetLJqzd. You will need a Mozilla LDAP account.

Expected result

No white line.

Actual result

The black video player has a white vertical line running down the middle. See the attached screenshot. If you play the video, the white line remains behind the video or turns into a shorter red or blue line behind the video.

I can reproduce on both Windows and macOS. On Windows, I can reproduce with gfx.webrender.software.d3d11 = true or false.

This is not a recent regression. I can reproduce the white line in Firefox 86, 87 Beta, and 88 Nightly.

OS: Windows → All
Severity: -- → S3
Priority: -- → P3

I could also reproduce the problem on my Win10 PC.

I can reproduce on Windows 10 as well.

Blocks: gfx-triage

The white line only happens when the video element has a border-radius.

Interestingly enough adding opacity to the video makes the white line move/disappear

Also, sort of weird, it seems to depend on the contents of the video itself as the line will move to different spots depending on the place in the video.

The line occurs due to the use of clip-masking creating a tile boundary. The SWGL YUV fast-path uses
saturated math and clamping to adequately deal with this issue, but when we fall off the fast-path
at the boundary, the main shader itself does not do any such clamping. When the generated negative
RGB values hit the blend stage and it tries to clip-mask it, it generates a bogus result.

To avoid this, it is sufficient to ensure that we clamp the Y value to be positive, if there is an
invalid Y value inside the headroom of the encoding space. This should only add a single SIMD
instruction to the alpha-pass variant without negatively impacting the other variants.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
No longer blocks: gfx-triage
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5ae1cfa6fc11
Avoid negative Y values in brush_yuv_image that can break blending in SWGL. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
QA Whiteboard: [qa-88b-p2]
Blocks: 1703402
See Also: → 1710144
You need to log in before you can comment on or make changes to this bug.