Fractional scaling goes east

When we introduced HiDPI support in GNOME a few years ago, we took the simplest possible approach that was feasible to implement with the infrastructure we had available at the time.

Some of the limitations:

  • You either get 1:1 or 2:1 scaling, nothing in between
  • The cut-off point that is somewhat arbitrarily chosen and you don’t get a say in it
  • In multi-monitor systems, all monitors share the same scale

Each of these limitations had technical reasons. For example, doing different scales per-monitor is hard to do as long as you are only using a single, big framebuffer for all of them. And allowing scale factors such as 1.5 leads to difficult questions about how to deal with windows that have a size like 640.5×480.5 pixels.

Over the years, we’ve removed the technical obstacles one-by-one, e.g. introduced per-monitor framebuffers. One of the last obstacles was the display configuration API that mutter exposes to the control-center display panel, which was closely modeled on XRANDR, and not suitable for per-monitor and non-integer scales. In the last cycle, we introduced a new, more suitable monitor configuration API, and the necessary support for it has just landed in the display panel.

With this, all of the hurdles have been cleared away, and we are finally ready to get serious about fractional scaling!

Yes, a hackfest!

Jonas and Marco happen to both be in Taipei in early June, so what better to do than to get together and spend some days hacking on fractional scaling support:

https://wiki.gnome.org/Hackfests/FractionalScaling2017

If you are a compositor developer (or plan on becoming one), or just generally interested in helping with this work, and are in the area, please check out the date and location by following the link. And, yes, this is a bit last-minute, but we still wanted to give others a chance to participate.

9 thoughts on “Fractional scaling goes east”

  1. Does having per-monitor framebuffers imply in the future connecting/disconnecting an external screen/projector will no longer cause the internal laptop screen to flicker?

  2. Taiwan #1. Also, fantastic work, looking forward to setting your progress.

  3. Hi,

    Welcome to Taipei!

    I don’t think I am able to help directly with this, but for the GTK+ regard on Windows when I was working on the HiDPI support for Windows we currently need to use a system (rather than per-monitor) DPI awareness scheme from the system, and Windows will scale the window automatically according to the scale that is deduced from the monitor where the majority of the window is on (unless of course, the scale is set using GDK_SCALE, where it will be fixed as a result)

    Definitely looking forward to fractional scaling support and per-monitor DPI scaling, and perhaps we can go to use per-monitor DPI awareness scheme on Windows.

  4. Amazing news. So much could be done to ease mixed dpi display setups. Switching between the seperate with spaces with external monitors for my laptop is such a big chore with managing xrandr scripts under x sessions.
    On an adjacent feature, is there anything in this related to wargame display Resolution querying, in cases like games on windowed mode, they fail to get anything other than the full 4k Resolution in their options on my current setup. The internal game settings dialogue seems to need to be offered a list of possible windowed resolutions you can sent, and Wayland doesn’t offer anything other than full display dimensions to whatever it queries.
    In terms of fractional scaling, I don’t know how that will be affected by this same query either.

  5. How will you handle fractional scaling on Wayland which only allows integer scaling?

    1. At first, by upscaling in the client, and downscaling in the compositor. But there’s also some idea of doing a Wayland protocol extension.

Comments are closed.