Xpra trac archive

Xpra: Ticket #2455: xpra-shadow new borders and window size miscalculations

After changing to the "new window styles" (between r24005 and r24195), I noticed that the shadow works "a bit differently"

Please see attached images.

  1. Image may not be fully initialized

  1. Viewport calculation is wrong
  2. On fullsize, viewport is correct, but other monitors "seep in"

I am not complaining so much about (3), but, if client could scale shadow window to perfectly fit the client's available viewport for maximized windows (i.e. window + the Start bar), then this would bring unnecessary drawing outside of the screen.

I don't know if client would be able to do that with Shadow windows (i.e. make the scaling fill pixel-perfectly the whole screen), but it would be a nice feature (reported in #2458).


Sat, 19 Oct 2019 09:43:49 GMT - stdedos: attachment set

Sat, 19 Oct 2019 09:43:58 GMT - stdedos: attachment set

Sat, 19 Oct 2019 09:47:58 GMT - stdedos: 

--- /a/description	2019-10-19 12:50:17.900970048 +0300
+++ /b/description	2019-10-19 12:50:17.900970048 +0300
@@ -1 +1 @@
-* On fullsize, viewport is correct, but other monitors "seep in"
+* On full screen, viewport is correct, but other monitors "seep in"

$ xpra version
xpra for python 2.7 is not installed
 retrying with python3
3.0-r24095
$ lsb_release -rd
Description:	Ubuntu 16.04.6 LTS
Release:	16.04

client: 

Windows 10
Xpra GTK3 client version 4.0-r24195 64-bit

Sat, 19 Oct 2019 11:39:49 GMT - stdedos:

"New window style" updates were done on r24164? Intentionally or Unintentionally?

Sun, 20 Oct 2019 11:14:51 GMT - Antoine Martin: owner changed

Image may not be fully initialized

Is the grey area the xpra client showing a shadow server? How long does it stay like that?

Viewport calculation is wrong

Too big or too small? xpra info output would show us what it is trying to do.

On fullsize, viewport is correct, but other monitors "seep in"

"viewport" - are those monitors? How many monitors? How much do they "seep in" by?

but, if client could scale shadow window to perfectly fit the client's available viewport for maximized windows .. I don't know if client would be able to do that with Shadow windows (i.e. make the scaling fill pixel-perfectly the whole screen), but it would be a nice feature.

This would be a different feature request (we may have a ticket already)

"New window style" updates were done on r24164? Intentionally or Unintentionally?

Are you sure that this changeset does something? How did you identify it? As far as I can tell, it just moves things around and merges two modules. There is only one opengl backend supported in v4, the "native" one.

Sun, 20 Oct 2019 12:34:13 GMT - stdedos:

Replying to Antoine Martin:

Xpra_cmd_2019-10-19_12-25-26.png Full sized window being partially drawn

Xpra_cmd_2019-10-19_12-28-34-1.png Maximized window being fully drawn, but missing screen image from below (need to compare with the next one)

Xpra_cmd_2019-10-19_12-30-04-2.png Full screen window containing the missing portion of the screen (from above), and the next screen (DP-4) being "glued" together with DP-2

Image may not be fully initialized

Is the grey area the xpra client showing a shadow server?

Yes

How long does it stay like that?

Until "some change" is made - manipulating the size of the xpra client window. Maybe when the screen is changed (new draws / mouse movement in that area), I haven't verified that one.

Viewport calculation is wrong

Too big or too small? xpra info output would show us what it is trying to do.

"Pushed down" from the new style of the window toolbar. You've added e.g. 100px above, the window needs to be "extended" downwards for that extra 100px.

On fullsize, viewport is correct, but other monitors "seep in"

"viewport" - are those monitors? How many monitors? How much do they "seep in" by?

3 monitors in total - from left to right DP-{0,2,4}. They don't hide anything from the existing screen (i.e. DP-2), but they simply "manifest" on full screen

but, if client could scale shadow window to perfectly fit the client's available viewport for maximized windows .. I don't know if client would be able to do that with Shadow windows (i.e. make the scaling fill pixel-perfectly the whole screen), but it would be a nice feature.

This would be a different feature request (we may have a ticket already)

Have another one :-D #2458

"New window style" updates were done on r24164? Intentionally or Unintentionally?

Are you sure that this changeset does something? How did you identify it? As far as I can tell, it just moves things around and merges two modules. There is only one opengl backend supported in v4, the "native" one.

I am not sure, I have gone through all patchsets from r24005 to r24195 manually. The only thing that could have possible looked like being "close" to this one was that. Of course, I can be wrong.

Sun, 20 Oct 2019 18:55:28 GMT - stdedos: attachment set

Mon, 21 Oct 2019 10:12:27 GMT - stdedos: attachment set

Mon, 21 Oct 2019 10:13:54 GMT - stdedos:

"Everything seems to be as it should be" (from xpra info 0 | grep -P '1920|2560'), but I cannot be sure.

That new style window toolbar does not appear to be windows-native, and I am not sure how much Windows likes that or not.

Mon, 21 Oct 2019 10:22:35 GMT - Antoine Martin:

That new style window toolbar does not appear to be windows-native, and I am not sure how much Windows likes that or not.

Are you sure you're not comparing GTK2 with GTK3 builds?

Mon, 21 Oct 2019 10:24:34 GMT - stdedos:

This is how I look for new Windows versions for a long time:

https://www.xpra.org/beta/windows/?C=M&O=D&P=*ython3*r24*.zip*

(obviously I change r24 accordingly)

Mon, 21 Oct 2019 10:28:53 GMT - Antoine Martin:

This is how I look for new Windows versions for a long time: ..

All downloads currently in the beta area are based on GTK3. Right around the time of what you call "windows-native", the default was changed from GTK2 to GTK3. The older Python2 builds were simply named "Xpra*". (though, going forward, the 3.0 builds will now have "Python2" or "Python3" to make it easier to distinguish)

Mon, 21 Oct 2019 10:29:58 GMT - Antoine Martin:

So, what I mean is this: if the bug occurs with 3.0, please try both the latest python2 and python3 builds so we know if the bug comes from the switch to gtk3 (python3).

Mon, 21 Oct 2019 11:53:09 GMT - stdedos:

The latest build I could find was Xpra-x86_64_3.0_r24039

Neither r24039 nor py3 r24005 exhibit this issue. If there is a py3-gtk3 and py2-gtk2 build somewhere, please provide the links and I'll retry testing.

Mon, 21 Oct 2019 16:11:48 GMT - Antoine Martin:

If there is a py3-gtk3 and py2-gtk2 build somewhere, please provide the links and I'll retry testing.

The beta area: https://xpra.org/beta/windows/ Has both python2 and python3 builds of 3.0.1RC. The stable area https://xpra.org/dists/windows/ Also has both python2 (unprefixed) and python3 builds.

Mon, 21 Oct 2019 19:57:16 GMT - stdedos: owner changed

https://xpra.org/beta/windows/Xpra-Python2-x86_64_3.0.1-r24232.zip does not exhibit such issue.

Drawing, contents, etc - everything is complete and as expected.

Thu, 26 Mar 2020 10:22:25 GMT - Antoine Martin: owner, status, milestone changed

See also #530

Thu, 26 Mar 2020 10:25:17 GMT - stdedos: description changed

Sat, 09 May 2020 04:45:12 GMT - Antoine Martin: priority changed

Geometry related tickets: #2618, #2516, #2600, #1941. Raising.

Mon, 28 Dec 2020 15:14:39 GMT - Antoine Martin: milestone changed

Sat, 23 Jan 2021 05:51:44 GMT - migration script:

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