Window scaling (aka owner sizes)

[Giuseppe Bilotta]

On Fri, Aug 31, 2018 at 6:53 AM Keith Packard <keithp at keithp.com> wrote:
> The root window size shouldn't be all that interesting to applications;
> they really need to know the monitor sizes and positions, and that
> information is available via RandR and Xinerama. So, I'm not all that
> concerned about root window size; applications relying on that are
> already broken.

Well, the “global” (legacy) display size is still used by applications
to get the global DPI as an Xft.dpi fallback (well, except for GTK3
for a while now), and Qt uses it in its mixed-DPI support (with the
appropriate environment variable, it sets the internal per-window
scaling based on the monitor DPI and the ratio of the global DPI to
the DPI of the primary monitor). So arguably we could say that any
application that does care about the legacy display size already has
_some_ form of DPI support, so there should be no need to manipulate
the reported value.

> Ok, so to make this 'actually' work, I might have to scale not only the
> window size, but the window position as well -- and then I might
> actually have to scale *all* of the window sizes and positions for the
> specified application.

> Or, maybe we create a synthetic monitor and then pretend to applications
> that their windows appear there instead.

If the server is trapping screen resizing requests, then yes, one of
these solutions would probably be necessary. The synthetic monitor is
a very clean solution; the biggest danger is the “undebuggability” of
the situation, unless xrandr  (the tool) is extended to be able to
peek into the per-application fake monitors as well. Or is this only
for Xwayland?

> I didn't want to change the owner position of the windows, but I now
> wonder if that might not turn out ok?

If you are meddling with global or RandR/Xinerama sizing, then yes,
you probably need to scale the positions as well, since otherwise the
application would be unable to do an e.g. “fake fullscreen” by setting
a window size _and_ coordinates to match those of a Xinerama screen.
However, “deep” scaling has a lot of corner cases where it may break
down (e.g. do you also scale the value reported by Xft.dpi or
Xcursor.size?) Also, what happens with multi-monitor setups? Do you
only scale values for one of the monitors, or the whole setup?

Consider the following setup (monospace required; and no, it's not
made up, it's one of my actual setups):

+-------+-------------+
|       |             |
|       |     L       |
|       |             |
|   V   +-------------+
|       |             |
|       |     H       |
|       |             |
+-------+-------------+

where V and L are standard-DPI monitors (say 1080p) with V rotated and
L in portrait mode, and H is high DPI (say 4K) in portrait mode. H is
the primary monitor, so when one “fullscreens” a game, that's
generally going to happen on H. How does the scaling work if the game
requests a fullscreen after a resizing of H? What happens if the same
thing is done without V and L, or with V put on the right instead of
the left? Or with a V1 on the left and a V2 on the right?

-- 
Giuseppe "Oblomov" Bilotta