Sorry for potentially duplicate email, the first one has messed up receiver addresses.
On Sun, 26 Aug 2018 23:24:09 -0700 kei...@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
pgpnANwKrN2cr.pgp
Description: OpenPGP digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel