Closed Bug 1722450 Opened 3 months ago Closed 2 months ago

[Wayland][WebRender] Heavy flickering during scale change


(Core :: Widget: Gtk, defect, P2)




93 Branch
Tracking Status
firefox93 --- fixed


(Reporter: stransky, Assigned: stransky)


(Blocks 1 open bug)



(4 files)

When [Wayland][WebRender] is used Firefox shows heavy flickering during scale changes.

Scale change can happen in multi-monitor scenario when a window is moved on screen edge and window decorations/shadows touch another monitor.

From my debugging of a similar issue, Firefox will commit a new buffer scale immediately when firefox is moved between screens. Instead, it should render a new buffer, set new buffer scale, and commit the surface.

I managed to reduce some flickering but the main issue is that content (child) process updates the web content slowly so we need to pause compositor and resume it when web content is reflown/composited for the new scale/size.

  • Set mozcontainer scale only when we're going to paint into it.
  • Set scale to EGL window with window size update at nsWindow::SetEGLNativeWindowSize().
  • Don't fire configure events for scale changes as we handle scale change by OnScaleChanged().
  • Remove redundant layout updates from nsWindow::OnScaleChanged().
  • Dont pass allocation size to OnScaleChanged() as it's not provided by the Gtk signal.
  • Log updates

We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.

In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).

Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.

Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.

Changes in the patch:

  • Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
  • Track nsWindow compositor state by WindowCompositorState
  • Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
  • Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
  • Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.

Depends on D121649

Attachment #9234520 - Attachment description: Bug 1722450 [Wayland] Pause compositor when screen scale changes and content is not updated yet, r?sotaro → Bug 1722450 [Wayland] Pause compositor when screen scale changes and content is not updated yet, r?sotaro,rmader

nsWindow on Linux is accessed from Compositor thread so we need to make it thread safe.

Depends on D121650

GtkCompositorWidget and WindowSurfaceWayland objects are used in Compositor thread and we should hold reference to nsWindow to make sure we don't release nsWindow early.

Depends on D122072

Pushed by
[Wayland] Reduce window changes during scale changes, r=rmader
[Wayland] Pause compositor when screen scale changes and content is not updated yet, r=sotaro
Make nsBaseWidget class thread safe, r=emilio
[Linux] Hold reference to nsWindow in GtkCompositorWidget/WindowSurfaceWayland, r=emilio

Robert, as this landed in 93 you may need to re-introduce the hack for Wayland compositor.

Flags: needinfo?(robert.mader)
Regressions: 1725371

Thanks, will do!

Flags: needinfo?(robert.mader)
Regressions: 1730031
You need to log in before you can comment on or make changes to this bug.