After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726743 - hi-dpi support for Boxes
hi-dpi support for Boxes
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: spice
unspecified
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-03-19 21:08 UTC by Owen Taylor
Modified: 2018-01-11 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2014-03-19 21:08:09 UTC
I did some testing of Boxes on a hi-dpi screen, and it basically works, not perfectly. 

In guest resizing mode only half the resolution is exposed to the guest, and then the guest contents are upscaled by a factor of 2 using bilinear scaling, resulting in a blurry appearance.

This is better than just exposing the full screen resolution to unsuspecting guests and having everything tiny - but generally a hi-dpi laptop screen is not going to have enough screen real estate to make the guest resizing resizing work well - my 2560x1440 laptop screen is 1280x720 when halved. A window that's smaller than that is not going to have much vertical real estate, and would be better scaled down.

Improvements that make sense to me:

 * If spice-gtk is rendering at an integer scale factor, it should set the filter to nearest-neighbour.

I added to spice-widget-cairo.c:

        cairo_set_source_surface(cr, d->ximage, 0, 0);
+        if ((int)s == s)
+            cairo_pattern_set_filter (cairo_get_source (cr),
+                                      CAIRO_FILTER_NEAREST);
        cairo_fill(cr);

 * There should be support for guests that have hi-dpi support themselves - this would be a new toggle in settings. In this case, guest resizing would give the guest a size that is exactly the pixel size of the window (use gtk_widget_get_scale_factor()) and a *physical size* would be exposed to the guest that corresponds to a dpi of 96dpi * scale factor. [Rounding down the physical dimensions to so that the result is strictly >= than 192dpi for a scale of two.]

Beyond that, I'm not sure what is needed to facilitate using non-hdpi guests at scales of 1 < scale < 2 (or hi-dpi guests at scales of 0.5 < scale < 1) which is a natural thing to do on a screen with high resolution but limited real estate.

Ideas I had:

 * Nothing - you just have to turn off guest resizing and set the resolution of the guest in the guest's hardware settings.

 * Expose resolution setting in the box properties - this would be more convenient if you need to change it frequently. If guest resizing is reliable enough, then setting the resolution from within Boxes should be reliable enough.

 * Some sort of floating point scale slider within the Boxes properties that affects the result of guest resizing so that the user could set a scale of 0.75 and a 600x400 window would result in a guest size of 800x533.

 * Some sort of smart resizing algorithm that would pick an appropriate guest size based on a) scaling-factor b) window size c) considerations of what's going create a maximally usable guest - balancing having enough screen real estate without making things too tiny.

The third option seems against the minimalist spirit of Boxes preferences. I think the fourth could work, though the algorithm takes some thinking.
Comment 1 Zeeshan Ali 2015-05-21 22:24:13 UTC
Hmm.. when guest has spice-guest-tools installed (which they are if express installed or most linux OSs), spice dictates resolution to the guest based on window size so I think it should be spice that should handle scaling factors as well, depending on client/host scaling factor? Am I making any sense?
Comment 2 Zeeshan Ali 2015-07-06 14:30:40 UTC
(In reply to Zeeshan Ali (Khattak) from comment #1)
> Hmm.. when guest has spice-guest-tools installed (which they are if express
> installed or most linux OSs), spice dictates resolution to the guest based
> on window size so I think it should be spice that should handle scaling
> factors as well, depending on client/host scaling factor? Am I making any
> sense?

Owen?
Comment 3 Owen Taylor 2015-07-06 14:45:34 UTC
(In reply to Zeeshan Ali (Khattak) from comment #1)
> Hmm.. when guest has spice-guest-tools installed (which they are if express
> installed or most linux OSs), spice dictates resolution to the guest based
> on window size so I think it should be spice that should handle scaling
> factors as well, depending on client/host scaling factor? Am I making any
> sense?

Are you asking whether this bug can simply be forwarded to Spice, without involvement from Boxes? Well - read through my comments in detail above - there are certainly parts that are Spice, but there are also suggestions that there might need UI changes in boxes. If we don't need any of those UI changes, or changes to the toplevel behavior of windows, then it would be entirely handled within Spice...
Comment 4 Zeeshan Ali 2015-07-08 17:41:15 UTC
(In reply to Owen Taylor from comment #0)
> I did some testing of Boxes on a hi-dpi screen, and it basically works, not
> perfectly. 
> 
> In guest resizing mode only half the resolution is exposed to the guest, and
> then the guest contents are upscaled by a factor of 2 using bilinear
> scaling, resulting in a blurry appearance.

Scaling only kicks in if guest doesn't have spice-vdagent installed or lacking QXL. In case of express installation (which we really want to be the norm here), these both are installed and therefore there shouldn't be any scaling involved but rather guest is supposed to reset it's resolution automatically based on window size.

Perhaps spice should (if it doesnt already), take scaling factor into account?
Comment 5 Zeeshan Ali 2015-07-08 17:45:50 UTC
(In reply to Owen Taylor from comment #3)
> (In reply to Zeeshan Ali (Khattak) from comment #1)
> > Hmm.. when guest has spice-guest-tools installed (which they are if express
> > installed or most linux OSs), spice dictates resolution to the guest based
> > on window size so I think it should be spice that should handle scaling
> > factors as well, depending on client/host scaling factor? Am I making any
> > sense?
> 
> Are you asking whether this bug can simply be forwarded to Spice, without
> involvement from Boxes? Well - read through my comments in detail above -
> there are certainly parts that are Spice, but there are also suggestions
> that there might need UI changes in boxes. If we don't need any of those UI
> changes, or changes to the toplevel behavior of windows, then it would be
> entirely handled within Spice...

To keep Boxes UI simple, the stress has always been to minimize adding of options whenever possible. So each time someone suggest adding a new option, my first question is: Can this not be done automatically? In this particular case, is there some information that spice-gtk can not collection from the client/host system and convey it to guest through it's agent, to make hidpi work out of the box?
Comment 6 Owen Taylor 2015-07-08 18:50:43 UTC
Two cases:

 * Guest operating system doesn't support hi-dpi. (At least RHEL < RHEL 7, Windows < Windows 8.1, most versions of Ubuntu, etc.) Passing through the host resolution hurts rather than helps, since you replace scaled content with *tiny* content.

 * Guest operating system supports hi-dpi. Then spice/spice-vdagent have the task of passing through the hi-dpi nature of the display, either using explicit OS facilities, or by presenting a high enough physical resolution (if the physical resolution is 192 or greater, then GNOME uses hi-dpi.)

If the spice or spice-vdagent protocol was extended to support advertising hi-dpi support from the client, then it's conceivable that the choice between the two could be made automatic in boxes - you get half resolution (with the no-fuzzy-fix hopefully!) until you install the agent.

That would cover the first half of my request, it doesn't solve the second half, where I found that my 2560x1440 (double-1280x720) screen was too small to have a useful windowed guest that whether 2x hi-dpi or 2x scaled, but a scaling a larger guest down worked well. It's possible that's WONTFIX within the limited UI goals of Docker, though it would have been useful to me.
Comment 7 Matthias Clasen 2016-04-19 17:13:36 UTC
So, my reading of what Owen is asking for here is essentially 3 separate requests:

1) Fix blurryness of integer scaling (there's some proposed spice change in the first comment for this).

2) Communicate hi-dpi display to guests (in a smart way, see the previous comment on what that means, depending on whether the guest supports hi-dpi or not).

3) Consider adding a new feature to boxes that would let users set a scale factor (independent of resolution changes via window resizing).
Comment 8 Zeeshan Ali 2016-04-19 17:18:28 UTC
(In reply to Matthias Clasen from comment #7)
> So, my reading of what Owen is asking for here is essentially 3 separate
> requests:

Thanks for summarizing.

> 1) Fix blurryness of integer scaling (there's some proposed spice change in
> the first comment for this).
> 
> 2) Communicate hi-dpi display to guests (in a smart way, see the previous
> comment on what that means, depending on whether the guest supports hi-dpi
> or not).

I think 2) would also lie entirely in spice layers.
 
> 3) Consider adding a new feature to boxes that would let users set a scale
> factor (independent of resolution changes via window resizing).

And this would be needed as work around for the case where guest doesn't support hidpi?
Comment 9 Matthias Clasen 2016-04-19 17:53:35 UTC
(In reply to Zeeshan Ali (Khattak) from comment #8)
> (In reply to Matthias Clasen from comment #7)
> > So, my reading of what Owen is asking for here is essentially 3 separate
> > requests:
> 
> Thanks for summarizing.
> 
> > 1) Fix blurryness of integer scaling (there's some proposed spice change in
> > the first comment for this).
> > 
> > 2) Communicate hi-dpi display to guests (in a smart way, see the previous
> > comment on what that means, depending on whether the guest supports hi-dpi
> > or not).
> 
> I think 2) would also lie entirely in spice layers.

As I said on irc, regardless where the code ends up, boxes gets judged for (the lack of) this feature

> > 3) Consider adding a new feature to boxes that would let users set a scale
> > factor (independent of resolution changes via window resizing).
> 
> And this would be needed as work around for the case where guest doesn't
> support hidpi?

No, read Owens description: He wanted it for a case where both the host and the guest were hi-dpi aware
Comment 10 GNOME Infrastructure Team 2018-01-11 10:08:01 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/24.