1578330 - [Windows] Glitches when resizing browser window with WebRender

Status: VERIFIED FIXED

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

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: resize_webrender.gif

Affected versions

• 70.0b3 (20190902191027)
• 71.0a1 (20190902213933)

Affected platforms

• Windows 10x64

Preconditions

• 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 constantly resize the browser from the bottom right.

Expected result

• No glitches are presented.

Actual result

• Glitches are presented on the top of the browser.

Regression range

• Last good revision: 98cbe150f012619bf9e8d44413fa33374e92dbc9 (2019-08-25)
• First bad revision: 0cf9eded35d8150796eda1f892666d0a778bd488 (2019-08-26)
• Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98cbe150f012619bf9e8d44413fa33374e92dbc9&tochange=0cf9eded35d8150796eda1f892666d0a778bd488

Additional Notes

• The issue is not reproducible on macOS 10.14 using the latest Nightly.
• I can reproduce the issue on Ubuntu but I think it’s bug 1547974.
• Attached a screen recording.

Comment 1

[Jessie [:jbonisteel] pls NI]

Glenn, any suggestions here?

Comment 2

[Jessie [:jbonisteel] pls NI]

Dzmitry, do you have any thoughts about this bug?

Comment 3

[Glenn Watson [:gw]]

It's possible this is a WR bug, although if it doesn't occur on Mac, it seems that it might be an issue in the Gecko-side Windows-specific code. Perhaps Sotaro might have some ideas or thoughts on where to investigate?

When I've looked at resizing bugs on Windows in the past, I know I've seen it working smoothly. So that suggests that we could probably get a mozregression range to narrow down when this broke, or perhaps that it's system / GPU specific if we can't find a (relatively) recent regression range.

Comment 4

[Jessie [:jbonisteel] pls NI]

Markus, could this be related to your changes in the regression range the reporter found?

Comment 5

[Markus Stange [:mstange]]

(In reply to Alexandru Trif, QA [:atrif] from comment #0)

Regression range

• Last good revision: 98cbe150f012619bf9e8d44413fa33374e92dbc9 (2019-08-25)
• First bad revision: 0cf9eded35d8150796eda1f892666d0a778bd488 (2019-08-26)
• Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98cbe150f012619bf9e8d44413fa33374e92dbc9&tochange=0cf9eded35d8150796eda1f892666d0a778bd488

I'm curious, how did you obtain this regression range? If you used mozregression, it should have continued checking autoland builds after it got the mozilla-central regression range, and the final regression range would have been smaller and even more helpful. If you didn't use mozregression, I hope you'll consider using mozregression in the future.

Final autoland regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=045217bb047625f7ba59febd30280d5adb2a02e0&tochange=717f127c6729b43ddc1f8b0ee22a3ce2abd57ae9

Comment 6

[Markus Stange [:mstange]]

(In reply to Jessie [:jbonisteel] plz needinfo from comment #4)

Markus, could this be related to your changes in the regression range the reporter found?

Yes, absolutely.

I think I've identified the responsible change:

-  if (!mCompositor->BeginFrame()) {
+  auto size = mCompositor->GetBufferSize();
+
+  if (mNativeLayerForEntireWindow) {
+    gfx::IntRect bounds(gfx::IntPoint(0, 0), size.ToUnknownSize());
+    mNativeLayerForEntireWindow->SetRect(bounds);
+#ifdef XP_MACOSX
+    mNativeLayerForEntireWindow->SetOpaqueRegion(
+        mCompositor->GetWidget()->GetOpaqueWidgetRegion().ToUnknownRegion());
+#endif
+  }
+
+  if (!mCompositor->BeginFrame(mNativeLayerForEntireWindow)) {
     if (mCompositor->IsContextLost()) {
       RenderThread::Get()->HandleDeviceReset("BeginFrame", /* aNotify */ true);
     }
+    mCompositor->GetWidget()->PostRender(&widgetContext);
     return false;
   }
 
   wr_renderer_update(mRenderer);
 
-  auto size = mCompositor->GetBufferSize();
-
   if (!wr_renderer_render(mRenderer, size.width, size.height, aHadSlowFrame,
                           aOutStats)) {

We were calling GetBufferSize after BeginFrame in the past, and now the order is reversed.

Comment 7

[Markus Stange [:mstange]]

[Tracking Requested - why for this release]: This is a pretty noticeable regression, we should make sure it doesn't slip into 70.

Comment 8

[Markus Stange [:mstange]]

Attachment: Bug 1578330 - Call GetBufferSize after BeginFrame because RenderCompositorANGLE mutates it in BeginFrame. r=mattwoodrow

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eaf0a4e2f21c
Call GetBufferSize after BeginFrame because RenderCompositorANGLE mutates it in BeginFrame. r=mattwoodrow

Comment 10

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/eaf0a4e2f21c

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Comment 12

[Alexandru Trif, Desktop Test Engineering [:atrif]]

(In reply to Markus Stange [:mstange] from comment #5)

I'm curious, how did you obtain this regression range? If you used mozregression, it should have continued checking autoland builds after it got the mozilla-central regression range, and the final regression range would have been smaller and even more helpful. If you didn't use mozregression, I hope you'll consider using mozregression in the future.

Final autoland regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=045217bb047625f7ba59febd30280d5adb2a02e0&tochange=717f127c6729b43ddc1f8b0ee22a3ce2abd57ae9

Hello Markus! Thank you for finding the final regression range. I didn’t notice at that time that my mozregression was not updated and I was getting a skipping build error when switching to autoland. I will consider updating mozregression regularly in the future. Thank you again and sorry for any inconvenience created.

The issue is verified using Firefox 71.0a1 (20190909095540) on Windows 10x64.

Comment 13

[Julien Cristau [:jcristau]]

Markus (or Matt since Markus is out at the moment), is this ready for uplift to beta70?

Comment 15

[Markus Stange [:mstange]]

Comment on attachment 9091329 [details]
Bug 1578330 - Call GetBufferSize after BeginFrame because RenderCompositorANGLE mutates it in BeginFrame. r=mattwoodrow

Beta/Release Uplift Approval Request

• User impact if declined: WebRender users will have jiggly window resizing.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just restores the old code path.
• String changes made/needed: none

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9091329 [details]
Bug 1578330 - Call GetBufferSize after BeginFrame because RenderCompositorANGLE mutates it in BeginFrame. r=mattwoodrow

Fix for webrender issue, let's uplift for beta 7.

Comment 17

[Oana Pop-Rus]

https://hg.mozilla.org/releases/mozilla-beta/rev/a7f28a80e295

Comment 18

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello,
The issue is verified fixed with Firefox 70.0b7 (20190916074538) on Windows 10x64. No glitches are shown on the top side of the browser when resizing with WebRender.