Window scaling (aka owner sizes)

Keith Packard keithp at
Mon Aug 27 06:24:09 UTC 2018

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <>

More information about the xorg-devel mailing list