Xpra: Ticket #1659: maximizing/demaximizing seamless apps from small vfb: positioning and redraw issues

This is similiar to issues with maximized/demaximized desktops already solved in #1656. I am opening a new ticket to avoid confusion.

If I have a vfb X server smaller than the client display, the application is well-drawn (and scaled up). If I maximize and de-maximize the application, the application is misplaced and mouse events do not match. Screenshot of thunar, maximized and de-maximized; the grey rectangle is a "file selector" dragged by the mouse. The right lower point of the rectangle is the mismatching current mouse position: http://up.picr.de/30630678az.png

(Aside from that, I think the applications should not be scaled up if the vfb is too small, but rather should be limited to the vfb size without scaling. I like the scaling possibility, but only as additional feature, not to level out different screen sizes automatically.)



Fri, 13 Oct 2017 12:37:43 GMT - mviereck: attachment set


Fri, 13 Oct 2017 12:38:01 GMT - mviereck: attachment set


Fri, 13 Oct 2017 13:03:14 GMT - mviereck:

Additional info: The bug is present in r17164 and r17165. Works well: r17160


Fri, 13 Oct 2017 15:11:38 GMT - Antoine Martin: owner changed

Please always include the command lines used to reproduce the problem. Is it a seamless session? A desktop session? Was this using Xephyr? From the server log, it looks like your display doesn't support XShm, why is that? This is probably what is causing the scaling:

Warning: adjusting scaling to accomodate server
 server desktop size is 1600x1200
 using scaling factor 1.2 x 1.2

Fri, 13 Oct 2017 16:53:14 GMT - mviereck:

Is it a seamless session? A desktop session?

It is a seamless session with a single application. I've hidden that detail in the title ;-).

Was this using Xephyr?

It was with Xdummy. I can reproduce it with Xephyr, too.

From the server log, it looks like your display doesn't support XShm, why is that?

Most times I use X servers without Xshm to work with GUI applications in docker containers. Containers don't have access to shared memory / IPC namespace. (Though, I can explicitly allow shared memory, but that reduces container isolation, something I want to avoid).

Please always include the command lines used to reproduce the problem.

Sample setup with Xephyr:

Xephyr :30
DISPLAY=:30 thunar
xpra start :30 --use-display --start-via-proxy=no
xpra attach :30

Maximizing and de-maximizing thunar shows the described effect.


Sun, 15 Oct 2017 11:12:46 GMT - Antoine Martin:

It was with Xdummy. I can reproduce it with Xephyr, too.

Based on the list of randr resolutions, I believe that the log samples used Xephyr, hence the confusion. FYI: Xephyr is not a good fit for desktop sessions - at least not without making the default resolution bigger so it won't trigger scaling so much.

I think the applications should not be scaled up if the vfb is too small, but rather should be limited to the vfb size without scaling.

That's simply impossible: the client and server screen size must match, scaling allows us to make it match. That's why it's there.

Containers don't have access to shared memory / IPC namespace. (Though, I can explicitly allow shared memory, but that reduces container isolation, something I want to avoid).

To maintain isolation and still get the drastic performance increase of mmap, you could restrict your container to a private shared memory area that only xpra can access: the mmap flag can be used to specify a path.

Maximizing and de-maximizing thunar shows the described effect.

Confirmed with any application, even an xterm.

The padding calculations needed to use the scaled render size, I didn't notice because I don't test with desktop scaling enabled often and my vfb (usually Xdummy) doesn't require it. The fixes are in r17189 + r17190.


Fri, 03 Nov 2017 12:13:42 GMT - Antoine Martin: status changed; resolution set


Tue, 27 Feb 2018 12:23:48 GMT - mviereck:

Thank you, the bug is fixed, I cannot reproduce it anymore. Sorry for late response.

To maintain isolation and still get the drastic performance increase of mmap, you could restrict your container to a private shared memory area that only xpra can access: the mmap flag can be used to specify a path.

Thank you for that hint. As I run xpra server and client both on host and only share the X unix socket with container, xpra automatically enables mmap, and the performance is great.


Sat, 23 Jan 2021 05:30:21 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1659