On Tue, 13 May 2025, Weifeng Liu wrote:
Hi,
On Tue, 2025-05-13 at 11:52 +0200, BALATON Zoltan wrote:
On Tue, 13 May 2025, Weifeng Liu wrote:
Hi,
On Tue, 2025-05-13 at 00:37 +0000, Kim, Dongwon wrote:
Hi,
Subject: [PATCH 8/9] ui/gtk-gl-area: Render guest content with
padding in
fixed-scale mode
In fixed-scale mode (zoom-to-fit=false), we expect that scale
should not
change, meaning that if window size is larger than guest surface,
padding is
# @zoom-to-fit: Zoom guest display to fit into the host window. When
# turned off the host window will be resized instead. In case
the
# display device can notify the guest on window resizes
# (virtio-gpu) this will default to "on", assuming the guest will
# resize the display to match the window size then. Otherwise it
# defaults to "off". (Since 3.1)
Current definition says the host window should be resized to fit the
size of the guest surface instead. Wouldn't padding accommodate this?
Yeah, window will be resized to fit the size of guest surface in fixed-
scale mode. However, users are still allowed to resize the window to a
larger size and this is case where padding is required, otherwise the
fixed-scale assumption is broken. In fact, gl=off mode employs padding
to preserve scale already but gl=on mode doesn't follow this behavior,
which, IMO, is a defect that this patch is trying to correct.
I think current set of switches is not enough to describe all possible
configs and this leads to inconsistency between display backends. Each
display backend has different idea on how zoom-to-fit should work now.
Maybe we need a new keep-aspect=off or similar option to make it explicit
then these can be set independently to decide if a full-screen zoom-to-fit
window should be stretched or padded. Currently it behaves differently
depending on display backend or even options of one display backend as you
say above. Fixing just one place won't solve the problem with other
backends so maybe separating this option into a new one would end this
inconsistency. I got requests from people for both padded or stretched
behaviour so it seems some prefer one or the other and just zoom-to-fit
can't set both.
Thank you for pointing out the demand for both stretched and padded
behavior — allowing users to choose their preferred display makes a lot
of sense. With the changes in this patch set, we can at least ensure
that all GTK-based backends behave consistently with regard to aspect
ratio. I’ll follow up with a separate patch set to introduce the new
keep-aspect=off (or similar) option you suggested.
By the way, I’ve also been working on a “scale” option to let users
specify an exact zoom level. I deliberately left it out of this patch
set because I wanted to keep its scope narrowly focused on refactoring.
Once this set is merged, I’ll submit the new patch set with these
changes.
A scale option would be a welcome change as well. I thought about that too
but did not try to implement it. One problem left may be that different
backends may be still inconsistent so if you only fix gtk others may need
to be adapted as well at some point (not necessarily by you but if you can
look at that and keep it consistent when making changes that would be
nice).
Regards,
BALATON Zoltan
