xpra-shadow new borders and window size miscalculations

[totaam]

Issue migrated from trac ticket # 2455

component: client | priority: critical

2019-10-19 10:43:20: stdedos created the issue

---

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

Please see attached images.

1. Image may not be fully initialized
   [[Image(Xpra_cmd_2019-10-19_12-25-26.png)]]
2. Viewport calculation is wrong
3. On fullsize, viewport is correct, but other monitors "seep in"
   [[Image(Xpra_cmd_2019-10-19_12-28-34-1.png)]]
   [[Image(Xpra_cmd_2019-10-19_12-30-04-2.png)]]

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

[totaam]

2019-10-19 10:43:49: stdedos uploaded file Xpra_cmd_2019-10-19_12-28-34-1.png (258.9 KiB)

[totaam]

2019-10-19 10:43:58: stdedos uploaded file Xpra_cmd_2019-10-19_12-30-04-2.png (297.5 KiB)

[totaam]

2019-10-19 10:47:58: stdedos commented

---

--- /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"

• Also, on full screen window, you cannot click wherever that "new window style" title bar would supposedly exist

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

client:

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

[totaam]

2019-10-19 12:39:49: stdedos commented

---

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

[totaam]

2019-10-20 12:14:51: antoine commented

---

• I'm not really sure what to look for on those screenshots

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.

[totaam]

2019-10-20 13:34:14: stdedos commented

---

Replying to [comment:3 Antoine Martin]:

• I'm not really sure what to look for on those screenshots

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 24195 manually. The only thing that could have possible looked like being "close" to this one was that. Of course, I can be wrong.

[totaam]

2019-10-20 19:55:28: stdedos uploaded file Xpra_cmd_2019-10-19_12-25-26.png (106.7 KiB)

[totaam]

2019-10-21 11:12:27: stdedos uploaded file xpra-info-2455.log (283.6 KiB)

[totaam]

2019-10-21 11:13:54: stdedos commented

---

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

[totaam]

2019-10-21 11:22:35: antoine commented

---

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?

[totaam]

2019-10-21 11:24:34: stdedos commented

---

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](../commit/2cff800bf4b6e388aefe640384410bf269041610)*.zip*

(obviously I change [r24](../commit/2cff800bf4b6e388aefe640384410bf269041610) accordingly)

[totaam]

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)

[totaam]

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

[totaam]

2019-10-21 12:53:10: stdedos commented

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

Neither 24039 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.

[totaam]

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.

[totaam]

2019-10-21 20:57:16: stdedos commented

---

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

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

[totaam]

See also #530

[totaam]

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

[stdedos]

Let's close this one in favor of #3140?