maximizing/demaximizing seamless apps from small vfb: positioning and redraw issues

[totaam]

Issue migrated from trac ticket # 1659

component: client | priority: major | resolution: worksforme

2017-10-13 13:36:56: mviereck created the issue

---

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.)

[totaam]

2017-10-13 13:37:43: mviereck uploaded file xpraserver.log (111.0 KiB)

[totaam]

2017-10-13 13:38:02: mviereck uploaded file xpraclient.log (11.9 KiB)

[totaam]

2017-10-13 14:03:14: mviereck commented

---

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

[totaam]

2017-10-13 16:11:39: antoine changed owner from antoine to mviereck

[totaam]

2017-10-13 16:11:39: antoine commented

---

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

[totaam]

2017-10-13 17:53:14: mviereck commented

---

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.

[totaam]

2017-10-15 12:12:46: antoine commented

---

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.

[totaam]

2017-11-03 12:13:42: antoine changed status from new to closed

[totaam]

2017-11-03 12:13:42: antoine set resolution to worksforme

[totaam]

2018-02-27 12:23:48: mviereck commented

---

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.