sw-wr: recorded Zoom video has a white line behind the video
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: cpeterson, Assigned: lsalzman)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
105.27 KB,
image/jpeg
|
Details | |
Bug 1698009 - Avoid negative Y values in brush_yuv_image that can break blending in SWGL. r?jrmuizel
48 bytes,
text/x-phabricator-request
|
Details | Review |
Steps to reproduce
- Enable
gfx.webrender.software
and restart Firefox. - 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.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
I could also reproduce the problem on my Win10 PC.
Comment 3•4 years ago
|
||
The white line only happens when the video element has a border-radius.
Comment 4•4 years ago
|
||
Interestingly enough adding opacity
to the video makes the white line move/disappear
Comment 5•4 years ago
|
||
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.
Assignee | ||
Comment 6•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 8•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•