Window scaling (aka owner sizes)
ppaalanen at gmail.com
Mon Aug 27 07:34:17 UTC 2018
Sorry for potentially duplicate email, the first one has messed up
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.
> 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
I believe this is awesome news for Xwayland!
From a very quick read, it sounds like a solution specifically aimed at
cases like , 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
. I believe it could also be the solution for other similar issues
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the xorg-devel