xpra-shadow new borders and window size miscalculations

[stdedos]

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

2. Viewport calculation is wrong
3. 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).

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

• 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-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

[stdedos]

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

[Antoine Martin]

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

[stdedos]

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

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

[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?

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

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

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

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

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

[stdedos]

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.

[Antoine Martin]

See also #530

[Antoine Martin]

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

[migration script]

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