Closed Bug 1546371 Opened 8 months ago Closed 8 months ago

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


(Core :: Graphics: WebRender, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- wontfix
firefox68 --- verified


(Reporter: kvark, Assigned: kvark)



(Keywords: regression)


(2 files, 1 obsolete file)

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

Assignee: nobody → dmalyshau

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.

Try push (unlikely to show anything, but for sanity's sake) -

Alexandru, would you be able to test this change?

Flags: needinfo?(alexandru.trif)

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

Try push (unlikely to show anything, but for sanity's sake) -

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!

Flags: needinfo?(alexandru.trif)

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


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.

Flags: qe-verify+

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 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.

Attachment #9060141 - Attachment is obsolete: true

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.

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

Flags: needinfo?(alexandru.trif)

Hi, I can confirm the issue is no longer reproducible using the steps from comment 5 and using the provided try build: If more information is needed please let me know. Thank you!

Flags: needinfo?(alexandru.trif)
Pushed by
Switch render backend and API away from FramebufferPixel r=gw
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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.

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.

See Also: → 1547974

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.

OS: Unspecified → Windows
Hardware: Unspecified → Desktop
See Also: → 1543356
Summary: Follow-up on the window resizing glitches with WebRender → [Windows] Follow-up on the window resizing glitches with WebRender

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

Flags: qe-verify+
See Also: → 1578330
You need to log in before you can comment on or make changes to this bug.