On Sun, May 11, 2025 at 03:33:11PM +0800, Weifeng Liu wrote:
The existence of multiple scaling factors forces us to deal with
various
coordinate systems and this would be confusing. It would be
beneficial
to define the concepts clearly and use consistent representation
for
variables in different coordinates.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
---
ui/gtk.c | 65
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index 982037b2c0..9f3171abc5 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -800,6 +800,71 @@ void
gd_update_monitor_refresh_rate(VirtualConsole *vc, GtkWidget
*widget)
#endif
}
+/**
+ * DOC: Coordinate handling.
+ *
+ * We are coping with sizes and positions in various coordinates
and the
+ * handling of these coordinates is somewhat confusing. It would
benefit us
+ * all if we define these coordinates explicitly and clearly.
Besides, it's
+ * also helpful to follow the same naming convention for variables
+ * representing values in different coordinates.
+ *
+ * I. Definitions
+ *
+ * - (guest) buffer coordinate: this is the coordinates that the
guest will
+ * see. The x/y offsets and width/height specified in commands
sent by
+ * guest is basically in buffer coordinate.
+ *
+ * - (host) pixel coordinate: this is the coordinate in pixel
level on the
+ * host destop. A window/widget of width 300 in pixel coordinate
means it
+ * occupies 300 pixels horizontally.
+ *
+ * - (host) logical window coordinate: the existence of global
scaling
+ * factor in desktop level makes this kind of coordinate play a
role. It
+ * always holds that (logical window size) * (global scale
factor) =
+ * (pixel size).
+ *
+ * - global scale factor: this is specified in desktop level and
is
+ * typically invariant during the life cycle of the process.
Users with
+ * high-DPI monitors might set this scale, for example, to 2, in
order to
+ * make the UI look larger.
+ *
+ * - zooming scale: this can be freely controlled by the QEMU user
to zoom
+ * in/out the guest content.
+ *
+ * II. Representation
+ *
+ * We'd like to use consistent representation for variables in
different
+ * coordinates:
+ * - buffer coordinate: prefix fb
+ * - pixel coordinate: prefix p
+ * - logical window coordinate: prefix w
+ *
+ * For scales:
+ * - global scale factor: prefix gs
+ * - zooming scale: prefix scale/s
+ *
+ * Example: fbw, pw, ww for width in different coordinates
+ *
+ * III. Equation
+ *
+ * - fbw * gs * scale_x = pw
Well. That is one possible approach (and this is what qemu is doing
today, for historical reasons, because most code dates back to pre
high-dpi days).
A possible alternative would be to go for fbw * scale_x = pw, i.e.
let
the guest run in pixel coordinates instead of window coordinates.
The
guest would do the high-dpi scaling then. That requires setting
physical display width and height in ui_info, so the guest can figure
what the display resolution is and go into high-dpi mode if needed.