On Wed, 2025-05-14 at 13:50 +0200, BALATON Zoltan wrote: > On Wed, 14 May 2025, Weifeng Liu wrote: > > Hi Gerd, > > On Mon, 2025-05-12 at 13:46 +0200, Gerd Hoffmann wrote: > > > 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.li...@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. > > Does that assume the guest knows about hidpi and has its own scale > factor? > What if I want to run an old guest that cannot do hidpi on a modern > host. > Can I still specify a scale factor to scale it up to usable size? > That's a > use case I care about which might be unusual but does exist. >
Yeah, that use case will be supported by introducing a non-high-dpi compatibility mode as suggested by Gerd. In this mode, the guest images will be scaled by global desktop scale factor. Best regards, Weifeng > Regards, > BALATON Zoltan > > > > > Thanks for your suggestion. Sounds like code could be simplified > > and be > > much easier to understand in this way. I will investigate it on top > > of > > this change. > > > > Best regards, > > Weifeng > > > > > We probably also need a non-high-dpi compatibility mode for old > > > guests. > > > That mode would start with "zooming scale = global scale" instead > > > of > > > "zooming scale = 1", and the dpi calculation would have to > > > consider > > > that too. > > > > > > (maybe best done on top of this nice cleanup). > > > > > > take care, > > > Gerd > >
