Closed Bug 1628657 Opened 2 years ago Closed 1 year ago

White Line Flickers on with WebRender on when scrolling


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




Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- disabled
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- verified


(Reporter: rares.doghi, Assigned: aosmond)


(Blocks 2 open bugs, )



(2 files)

[Affected versions]:
Nightly 77.0a1

[Affected platforms]:
Platforms: Windows 10

Verify about:support and check Compositing = WebRender
if it's not enabled reach about:config and set gfx.webrender.all = true

Steps :

  1. Open the Firefox Browser and reach
  2. Scroll a bit up and down and watch the bottom of the first mirage (the one with the pink lines).

Expected Results :
There should be no graphical issues displayed.

Actual Results :
White flicker is displayed at the bottom of the first mirage when scrolling up or down.
This issue only occurs with WebRender on.
This issue occurs on Laptops as well as Desktops with Nvidia or Intel GPU's.

Attached video 2020-04-09_02h46_19.mp4

Rares, is gfx.webrender.compositor on as well when this issue happens? Can you reproduce it in release or just Nightly?

I can repro this on my mac, so probably not compositor related.

Blocks: wr-76
Priority: -- → P3

Andrew, could this be a snapping thing?

Blocks: wr-77
No longer blocks: wr-76
Flags: needinfo?(aosmond)

This issue occurs with both gfx.webrender.compositor = true/false.
With gfx,webrender.force-disabled = true this issue does not reproduce.

I believe so, there are two canvases with fractional heights at the boundary where the white line flashes.

Blocks: wr-snap

The original site has changed, but the Web Archive has a snapshot this still reproduces.

Yep they moved it, you can find it here as well : weirdly enough on some laptops, I was unable to reproduce it, on others it can still be seen as well as on the desktops we have.

I have a prototype working now, where we generate the transform needed for canvas (or any async image pipeline iframes really) during scene building instead of display list building. This is because we need the snapped sizes from scene building to properly calculate the transform. This fixes the white line issue for me. Putting together the final patch and tests now.

Assignee: nobody → aosmond
Flags: needinfo?(aosmond)

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Assignee: aosmond → nobody
Severity: normal → S3
Assignee: nobody → aosmond
Blocks: wr-78
No longer blocks: wr-77

When a transform depends on the layout size of an element, one can see
visual distortions caused by the difference between the unsnapped size
used in the transform, and the snapped size calculated during scene
building. Ideally we could compute the transform after we snap, rather
than before. This patch adds support for a computed reference frame
which takes parameters to calculate the ideal transform dynamically.

In a future patch, we should make videos take advantage of this same
mechanism to avoid similar problems. This requires support for mirroring
and rotations.

Blocks: wr-79
No longer blocks: wr-78
Pushed by
Make canvas use computed reference frame transforms. r=kvark
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Marking 78 as affected but this can ride the trains.

Has STR: --- → yes
OS: Windows 10 → All
Hardware: Desktop → All
Flags: qe-verify+

This issue is verified as fixed in our latest Nightly build as well as Beta 79.0b3 on Windows 10.

Flags: qe-verify+
Duplicate of this bug: 1636856
You need to log in before you can comment on or make changes to this bug.