ozone/wayland: mixed dpi: fix visual size [chromium/src : main]
Maksim Sisov (Gerrit)
Attention is currently required from: Kramer Ge.
Maksim Sisov would like Kramer Ge to review this change.
ozone/wayland: mixed dpi: fix visual size
The final size of the Wayland surface is determined by the buffer size
in px * scale that the Chromium compositor renders at. If the window
changes a display (and scale changes from 1 to 2), the buffers are
recreated with some delays. Thus, applying a visual size using
window_scale (which is the current scale of a wl_output where the
window is located at) is wrong, as it may result in a smaller visual
size than needed. For example, buffers' size in px is 100x100, the
buffer scale and window scale is 1. The window is moved to another
display and window scale changes to 2. The window's bounds also change
are multiplied by the scale factor. It takes time until buffers are
recreated for a larger size in px and submitted. However, there might be
an in flight frame that submits buffers with old size. Thus, applying
scale factor immediately will result in a visual size in dip to be
smaller than needed. This results in a bouncing window size in some
scenarios like starting Chrome on a secondary display with larger scale
factor than the primary display's one.
In the case of test config, the visual size must be applied immediately
with the current display's scale factor.
Bug: 1252760, 1198965
Change-Id: Ief574edd391b23fb5643e1db996c1b6887d65959
---
M ui/ozone/platform/wayland/host/wayland_toplevel_window.cc
1 file changed, 52 insertions(+), 1 deletion(-)
To view, visit change 3211708. To unsubscribe, or for help writing mail filters, visit settings.
Maksim Sisov (Gerrit)
Attention is currently required from: Kramer Ge.
Kramer Ge (Gerrit)
Attention is currently required from: Maksim Sisov.
1 comment:
File ui/ozone/platform/wayland/host/wayland_toplevel_window.cc:
Patch Set #4, Line 426:
void WaylandToplevelWindow::UpdateVisualSize(const gfx::Size& size_px) {Would it make more sense to just give size_dip instead of size_px here?
To view, visit change 3211708. To unsubscribe, or for help writing mail filters, visit settings.
Kramer Ge (Gerrit)
File ui/ozone/platform/wayland/host/wayland_toplevel_window.cc:
Patch Set #4, Line 426:
void WaylandToplevelWindow::UpdateVisualSize(const gfx::Size& size_px) {Would it make more sense to just give size_dip instead of size_px here?
In the future this pending_state_.scale can be different from state_.scale. Caller of this function should know which scale it is applying better IMO.
To view, visit change 3211708. To unsubscribe, or for help writing mail filters, visit settings.
Maksim Sisov (Gerrit)
Attention is currently required from: Kramer Ge.
1 comment:
File ui/ozone/platform/wayland/host/wayland_toplevel_window.cc:
Patch Set #4, Line 426:
void WaylandToplevelWindow::UpdateVisualSize(const gfx::Size& size_px) {
In the future this pending_state_.scale can be different from state_.scale. […]
The problem is that there are other places that rely on visual_size_px_, which WaylandWindow::UpdateVisualSize stores. Making UpdateVisualSize accept size in dip instead of px will result in unnecessary translations in places that shouldn't be doing that. Instead, UpdateVisualSize can accept additional parameter - scale factor. Will do so.
To view, visit change 3211708. To unsubscribe, or for help writing mail filters, visit settings.
Kramer Ge (Gerrit)
Attention is currently required from: Maksim Sisov.
Patch set 5:Code-Review +1
1 comment:
File ui/ozone/platform/wayland/host/wayland_toplevel_window.cc:
Patch Set #4, Line 426:
void WaylandToplevelWindow::UpdateVisualSize(const gfx::Size& size_px) {
The problem is that there are other places that rely on visual_size_px_, which WaylandWindow::Update […]
Cools.
To view, visit change 3211708. To unsubscribe, or for help writing mail filters, visit settings.
Maksim Sisov (Gerrit)
Attention is currently required from: Maksim Sisov.
Patch set 5:Commit-Queue +2
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted this change.
ozone/wayland: mixed dpi: fix visual size
The final size of the Wayland surface is determined by the buffer size
in px * scale that the Chromium compositor renders at. If the window
changes a display (and scale changes from 1 to 2), the buffers are
recreated with some delays. Thus, applying a visual size using
window_scale (which is the current scale of a wl_output where the
window is located at) is wrong, as it may result in a smaller visual
size than needed. For example, buffers' size in px is 100x100, the
buffer scale and window scale is 1. The window is moved to another
display and window scale changes to 2. The window's bounds also change
are multiplied by the scale factor. It takes time until buffers are
recreated for a larger size in px and submitted. However, there might be
an in flight frame that submits buffers with old size. Thus, applying
scale factor immediately will result in a visual size in dip to be
smaller than needed. This results in a bouncing window size in some
scenarios like starting Chrome on a secondary display with larger scale
factor than the primary display's one.
In the case of test config, the visual size must be applied immediately
with the current display's scale factor.
Bug: 1252760, 1198965
Change-Id: Ief574edd391b23fb5643e1db996c1b6887d65959
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3211708
Reviewed-by: Kramer Ge <fang...@chromium.org>
Commit-Queue: Maksim Sisov <msi...@igalia.com>
Cr-Commit-Position: refs/heads/main@{#931389}
---
M ui/ozone/platform/wayland/gpu/gl_surface_wayland.cc
M ui/ozone/platform/wayland/host/wayland_toplevel_window.h
M ui/ozone/platform/wayland/host/wayland_window.h
M ui/ozone/platform/wayland/host/wayland_window.cc
M ui/ozone/platform/wayland/host/wayland_toplevel_window.cc
M ui/ozone/platform/wayland/host/wayland_window_unittest.cc
6 files changed, 78 insertions(+), 19 deletions(-)