Visual glitches on resizing the browser with WebRender

VERIFIED FIXED in Firefox 67

Status

()

defect
P1
normal
VERIFIED FIXED
3 months ago
3 months ago

People

(Reporter: atrif, Assigned: gw)

Tracking

(Blocks 1 bug, Regression, {regression})

Trunk
mozilla68
Desktop
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox66 unaffected, firefox67 verified, firefox68 verified)

Details

Attachments

(3 attachments)

Posted image resize_glitch.gif

Affected versions

  • Firefox 68.0a1 (20190409221047)

Affected platforms

  • Windows 10 x64
  • Ubuntu 18.04 x64

[Prerequisites]:

  • Ensure that in about:support at Graphics section “Compositing” has the “WebRender” attribute, if not set gfx.webrender.all to true.
  • Possible Nvidia GPU needed for enabling WebRender.

Steps to reproduce

  1. Open Firefox and open at least 4 tabs.
  2. Continuously drag the browser from the bottom area to resize it and move the mouse up and down.
  3. Observe the tabs section.

Expected result

  • Browser is resized properly and no visual glitches are displayed.

Actual result

  • Visual glitches appear on tab section from the browser.

Regression range

Additional Notes

  • The issue is reproducible with only one tab opened but it’s more visible with more tabs.
  • I could not reproduce the issue on 66.0.3 (20190409155332) or 67.0b9 (20190408123043) even if I set gfx.webrender.all to true.
  • The issue is not reproducible on macOS 10.12 on latest Nightly with gfx.webrender.all set to true.
  • On my machine (GPU- Intel(R) HD Graphics 630) Nightly starts as default with Compositing to WebRender and setting layers.acceleration.disabled to true removes the issue and changes Compositing to Basic.
  • Attached a screen recording with the issue.
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
Component: Window Management → Graphics: WebRender

This is pretty annoying when resizing the window on Windows, so might be worth being high priority.

This is a regression caused by bug 1531217, but I believe Dzmitry is on PTO currently?

Severity: normal → major
Priority: -- → P1
Regressed by: 1531217
Severity: major → normal

Going to find someone to take a closer look at this today so we can determine urgency around fixing.

Assignee: nobody → gwatson

My findings so far:

  • I initially tried to revert the regressing patch. Unfortunately there are a large number of conflicts that are non-trivial to resolve.

  • After some debugging, I am fairly confident I can see the issue. The patch changes the target rect of the main frame buffer to be calculated during frame building time, rather than at render time. This doesn't work correctly during resizing, since the window size can change (a) between the frame build and the render occurring and (b) when re-rendering the same frame.

  • I tried to add a workaround / hack for the problem above. I think it improves it, however I was still seeing similar glitches during resizing. I then found out that these glitches occur on Linux even with WR disabled, and even before this patch landed, as long as GL layers are enabled. So it seems that there are two similar issues here (1) an existing issue on Linux + GL layers when resizing, and (2) the issues caused by this patch mentioned above. This makes it difficult to confirm if my workaround is helping.

Next steps:

  • Update my Windows dev environment and attempt to reproduce on there.

I have a couple of questions on priority of this bug:
(a) Are we confident it doesn't occur on the current 67 beta on Windows? If so, the priority is probably less urgent?
(b) What date do we think we must have a fix for this by?

Flags: needinfo?(jnicol)
Flags: needinfo?(jbonisteel)
Flags: needinfo?(alexandru.trif)

I tested locally on a Windows + nVidia machine. It seems to occur in both beta (67) and nightly (68) from what I can tell. It seems worse in the nightly, but I can definitely see resizing glitches in the 67 beta on Windows when WR is enabled. It'd be good if someone else could confirm that they see the same though.

Posted image webrender_01.gif

Hello, I can confirm the issue is reproducible on 67.0b11 (20190415085659) with WebRender on. Attached a screen recording on 67.0b11 with the issue. I didn’t notice that on the first place because it’s not reproducing on about:config page, but changing on a content loaded tab activates the glitch. I am sorry for misleading here. I can’t reproduce it on 66.0.3 (20190409155332) with WebRender on tho.

Flags: needinfo?(alexandru.trif)

No worries, thanks for the confirmation! That matches what I'm seeing, and the regression commit above landed after 66, so this also makes sense. I'll continue investigating on a Windows machine tomorrow.

Flags: needinfo?(jnicol)
Flags: needinfo?(jbonisteel)

This is a hack / workaround that seems to fix the resizing bug on Windows, and make it much better on Linux. It'd be great if we could get some testing on this to see if it causes any other issues (I'll be testing more with it locally today).

Comment from the code change:

This is a hack / workaround for a resizing glitch. What happens is that the framebuffer rect / content origin are determined during frame building, rather than at render time (which is what used to happen). This means that the framebuffer rect/origin can be wrong by the time a frame is drawn, if resizing is occurring. This hack just makes the framebuffer rect/origin be hard coded to the current framebuffer size at render time. It seems like this probably breaks some assumptions elsewhere, but it seems to fix the bug and I haven't noticed any other issues so far. We will need to investigate this further and make a "proper" fix.

Pending try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f31ad6dd51a6aedaecaf31a3d46311b0d1ee762

The try run looks good, and I haven't seen any issues in local testing so far.

I spent a bit of time today also testing the try build on Windows 10 (Intel GPU) and it looks good. It seems to resolve the glitching and I haven't seen any other weird behaviour or regressions.

Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b03a3303ad6e
Visual glitches on resizing the browser with WebRender. r=emilio
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Regressions: 1545767

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

(In reply to Pascal Chevrel:pascalc from comment #13)

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

So far it only caused a regression on an experimental and still disabled by default feature which won't be uplifted to 67.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #14)

(In reply to Pascal Chevrel:pascalc from comment #13)

Wontfix for 67 as we are late in the beta cycle and this patch caused another regression so we woudn't uplift.

So far it only caused a regression on an experimental and still disabled by default feature which won't be uplifted to 67.

Given that this is a disabled by default feature, let's mark it back as affected and see if an uplift is desirable.

An uplift for this is definitely desired - I was going to let it sit in nightly over the long weekend and request uplift on Monday if it doesn't break anything else.

Comment on attachment 9059121 [details]
Bug 1543356 - Visual glitches on resizing the browser with WebRender.

Beta/Release Uplift Approval Request

  • User impact if declined: Very noticeable rendering glitches during window resizing.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Ensure WebRender is enabled, and confirm that resizing the window does not show any glitches similar to the screen recording in the bug.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Low risk since (a) only affects users enrolled in WebRender on nVidia desktop + Win10, (b) Has been tested in nightly for a few days, (c) Is a small / simple patch that's easy to back out. The alternative is to ship with visual glitches during resizing for WebRender users.
  • String changes made/needed:
Attachment #9059121 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Hi, This issue is verified as fixed in our latest nightly build 68.0a1 (2019-04-21).

Comment on attachment 9059121 [details]
Bug 1543356 - Visual glitches on resizing the browser with WebRender.

Fixes visual glitches when resizing windows for users opted into WebRender trials. No impact on users who aren't. Approved for 67.0b13.

Attachment #9059121 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Dzmitry, when you are back from PTO, could you investigate what the right fix for this is (to fix the visual glitch without regressing doc splitting)? Feel free to ping me on IRC for more context.

Flags: needinfo?(dmalyshau)

Hi, I retested this issue In Firefox Beta 67.0b13 and the issue no longer occurs. I will mark this issue accordingly.

Status: RESOLVED → VERIFIED

Should we leave the QeVerify+ flag just in case more modifications are made and this needs to be retested on both Nightly and Beta ?

Created bug 1546371 to follow-up

Flags: needinfo?(dmalyshau)

Hi, I'm moving the QeVerify+ bug to the Follow up bug so we can keep track of it.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
See Also: → 1547974
See Also: → 1546371
You need to log in before you can comment on or make changes to this bug.