Window scaling (aka owner sizes)

[Olivier Fourdan]

Hi Keith,

On Mon, Aug 27, 2018 at 8:24 AM Keith Packard <keithp at keithp.com> wrote:
>
>
> I'm doing a bit of work to help support applications that want to run at
> a small fixed size. The 'usual' way to make them visible on our modern
> desktops is to flip video modes, but that means everything runs at low
> resolution, plus you get the adventure of switching modes, which can
> take a long time in complex monitor environments.
>
>         https://keithp.com/blogs/window-scaling/
>
> The basic plan is to make the size-as-seen-by-the-owner different from
> the size seen by the rest of the system, and then to either have the
> server scale the output or get the compositing manager to do it.
>
> This solves one of the main use cases for 'composite redirection' that I
> talked about a long time ago and could never get to work. Restricting
> the problem space to simple application scaling, instead of arbitrary
> transformation, meant that I could place the input event scaling right
> inside the X server, allowing it to be synchronous, instead of
> attempting to have some external agent perform the transformation.
>
> When there's no compositing manager running, the window is placed into
> automatic compositing mode and the X server performs the necessary
> output scaling.
>
> When there is a compositing manager running, I've thought of three
> possible ways to make it work:
>
>  1. The compositing manager can be extended to handle the scaling
>     operation. This seems like the best plan; just a single copy from
>     the native application size to the scanout buffer.
>
>  2. Alternatively, another window might be interposed between the scaled
>     client and the compositor to provide a place for the X server to do
>     the scaling; although that would naturally introduce a bunch more
>     expense and delay in the process.
>
>  3. It would also be possible to have the X server provide a scaled
>     version of the window pixmap to the compositing manager until it
>     advertised support for built-in scaling. Same rendering delay as
>     with an interposed window, but no changes required in the
>     environment, although a bit of work to be done in the X server. That
>     might be a good transition plan so that things didn't break when you
>     started a compositing manager without the required support.
>
> I'm wondering if there are others who would find this useful, and if
> some of them might help get this into reasonable shape. Suggestions are
> welcome!

Much interesting indeed :)

We've been considering something similar for Xwayland, scaling the
window is relatively easy, but one possible issue with scaling the
client window is the perception of the screen size from the client
itself.

Imagine the client is trying to size its window to match the screen or
even output size, or tries to center its window on the current
monitor. It does so based on the root window size or possibly the
Xrandr information or even Xinerama, but since its window will be
scaled afterwards, that computed size or position will end up being
wrong.

So that means that the screen size and xrandr info sent to the client
depends on the client's window being scaled or not, eventually.
Basically, the Xserver needs to lie to the client so that the client
computes its window size/position right when mapped on screen.

But things like DisplayWidth()/DisplayHeight() are defined as C macros
in Xlib, to access the fields of the Screen sent when opening the
connection with the Xserver, not something we can fix easily.

Moreover, several properties from EWMH on the root window reflect the
screen size (things like _NET_DESKTOP_GEOMETRY, _NET_WORKAREA) and are
necessarily shared between all X11 clients (who share the same root
window).

How do you plan to deal with this in your approach?

Cheers,
Olivier

PS: When considering this for Xwayland, I ended up thinking that it
would be actually easier to have different X11 screens (i.e. :0.0,
:0.1, etc.) of different size for different scales for the X11 clients
ended up being scaled differently (which led me to
https://gitlab.freedesktop.org/ofourdan/xserver/tree/xwayland-multi-screen),
but that approach introduces a lot of complexity (the CM has to play
the proxy between all those X11 screens for things like copy/paste,
DnD, etc.)