Window scaling (aka owner sizes)

[Robert Mader]

Hej Keith,

I've been working on this, too, for the XWayland case. It's only a proof
of concept, but I tested it successfully with a couple of fullscreen
apps (read: games).
When asking people in the IRC channel, the general consensus seemed to
be to go for option one, by making use of viewporter wayland protocol,
which is why implemented it for gnomes mutter (see 1, won't make it
before gnome 3.32).

There are also patches to expose all modes send by the compositor in
XWayland ( see 2) and to make XWayland use randr 1.2 hooks, which makes
things quite a bit easier (see 3).

I can post my WIP work (will have to clean it up and rebase to current
master).
That said, I'm very interested to see this go forward and am very
willing to help :)

Best regards,
Robert

1) https://gitlab.gnome.org/GNOME/mutter/merge_requests/121
2) https://patchwork.freedesktop.org/patch/191035/
3) https://bugs.freedesktop.org/show_bug.cgi?id=104644

On 27.08.2018 08:24, 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!
>
>
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180827/9b0230ab/attachment.html>