Window scaling (aka owner sizes)

[Pekka Paalanen]

Sorry for potentially duplicate email, the first one has messed up
receiver addresses.


On Sun, 26 Aug 2018 23:24:09 -0700
keithp at keithp.com ("Keith Packard") 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!  

Hi Keith,

I believe this is awesome news for Xwayland!

From a very quick read, it sounds like a solution specifically aimed at
cases like [1], where Xwayland is exposing just one video mode but
games expect to switch to a small one and we really would like to scale
them up instead.

Also HiDPI support, especially on a desktop with mixed DPI outputs, has
been considered an extremely difficult scenario to support on Xwayland
[2]. I believe it could also be the solution for other similar issues
[3].

There should be many people interested in this. I can't guess how it
should work on Xwayland, can Xwayland itself configure the scaling or
should it be driven from the X11 WM. It's definitely an interesting
idea.


Thanks,
pq

[1] https://bugs.freedesktop.org/show_bug.cgi?id=101193
[2] https://bugs.freedesktop.org/show_bug.cgi?id=93315
[3] https://bugs.freedesktop.org/show_bug.cgi?id=101436
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180827/6bd19e4a/attachment-0001.sig>