1546371 - [Windows] Follow-up on the window resizing glitches with WebRender

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Dzmitry Malyshau [:kvark]]

Bug 1543356 showed a regression with resizing after bug 1531217.
This issue is about revising the temporary hack and fixing this properly.

Comment 1

[Dzmitry Malyshau [:kvark]]

To clarify, I don't think there was ever a good story of WR handing the resize. Renderer always assumed that a frame built by the render backend matches the window in size, and it worked accidentally rather than by design. The changes I landed just exposed this.

Comment 2

[Dzmitry Malyshau [:kvark]]

Attachment: Adjust WR frame to the current window size

Comment 3

[Dzmitry Malyshau [:kvark]]

Try push (unlikely to show anything, but for sanity's sake) - https://treeherder.mozilla.org/#/jobs?repo=try&revision=9cada7ae19c623f88e049d88988d1cd533bb18b5

Alexandru, would you be able to test this change?

Comment 4

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

(In reply to Dzmitry Malyshau [:kvark] from comment #3)

Try push (unlikely to show anything, but for sanity's sake) - https://treeherder.mozilla.org/#/jobs?repo=try&revision=9cada7ae19c623f88e049d88988d1cd533bb18b5

Alexandru, would you be able to test this change?

Hello, I've tested the build you provided and the issue is still reproducible with WebRender. Still, setting layers.acceleration.disabled to true removes the glitch when resizing from the bottom. If there is other information I can help with please let me know. Thank you!

Comment 5

[Rares Doghi, Desktop QA]

Just a reminder that we can use the steps from Bug 1543356 in order to verify this fix :

[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

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

Set the qe-verify+ flag in order to keep track of this fix.

Comment 6

[Dzmitry Malyshau [:kvark]]

Thanks Rares and Alexandru, this is helpful. For some reason, not all pages/tabs are affected. Opening 4 of them makes it easy to see the problem (even with this patch).

Here are the findings so far:

1. main relevant difference of https://phabricator.services.mozilla.com/D21641 is that we used to set both the viewport and the projection to the full extent of the framebuffer size (provided by Gecko). Now we are setting them from the rectangle and content origin that render backend was working on when building the frame. This rect can technically be outdated if the window is resized.
2. on Linux, I see that even Gecko doesn't have up-to-date size of the main framebuffer. I captured a series of frames with RenderDoc at the time of resizing and added debug markers to show what WR thinks the size is - in some cases it's lagging behind the actual framebuffer size that RenderDoc captured.

With this in mind, I'm moving the investigation to Windows now, focusing on the (1) part.

Comment 7

[Dzmitry Malyshau [:kvark]]

Attachment: Switch render backend and API away from FramebufferPixel

The gist of the problem I introduced with the framebuffer coordinate system is that we provided the window rect (effectively) twice:

1. when computing the document rectangle (and Y-inverting it)
2. when rendering

If between these points the window got resized (during scene building), we end up with our document aligned to bottom left corner.
The user expects content to still be aligned to the top left, so that's what is visible as a bug.

The change here switched scene building to only care about device coordinate space, restraining the framebuffer coordinates to be mostly
an implementation detail of the renderer/device (the way it was originally meant to be, when introduced). This way the current window size
is only considered once during rendering.

Comment 8

[Dzmitry Malyshau [:kvark]]

:atrif, would you be able to test the new fix?

Comment 9

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

Hi, I can confirm the issue is no longer reproducible using the steps from comment 5 and using the provided try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=08ff766a297016cd7bfb56b25fce3fe0cbf6b0f5. If more information is needed please let me know. Thank you!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc316493ddae
Switch render backend and API away from FramebufferPixel r=gw

Comment 11

[Oana Pop-Rus]

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

Comment 12

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

Attachment: webrender_ubuntu18x64.mp4

Hello, I retested the fix on Firefox 68.0a1 (20190429215338) and the issue is no longer reproducible on Windows 10 x64 using WebRender. However, on a Ubuntu 18.04 the issue still occurs when using WebRender and setting layers.acceleration.disabled pref to true removes the issue. Attached a screen recording.

Comment 13

[Dzmitry Malyshau [:kvark]]

Alexandru,
Yes, Linux build is still subject to the issue, and the fix would be different from the one I landed. Basically, Gecko doesn't get up-to-date size of the window, so WebRender has no chance of catching up. I suggest we file a separate bug for it.

Comment 14

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

Thank you! I filled bug 1547974 for Ubuntu.
I will also modify flags and summary to easily keep track of them. If there is anything I can help with please let me know.

Comment 15

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

Hello! Closing this bug as verified and removing the qe+ flag since is no longer needed.