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.)
Additional info: The bug is present in r17164 and r17165. Works well: r17160
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
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.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1659