Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xpra start gnome-terminal window "is jumpy" #2457

Closed
totaam opened this issue Oct 19, 2019 · 25 comments
Closed

xpra start gnome-terminal window "is jumpy" #2457

totaam opened this issue Oct 19, 2019 · 25 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Oct 19, 2019

Issue migrated from trac ticket # 2457

component: client | priority: blocker | resolution: fixed

2019-10-19 11:23:15: stdedos created the issue


$ 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

For a lack of .... any good description, I'll let the video explain the issue :-)
It seems to "hate more" being "widened" than being "heightened".

@totaam
Copy link
Collaborator Author

totaam commented Oct 19, 2019

2019-10-19 11:24:40: stdedos uploaded file xpra-client_2019-10-19_12-54-27.mp4 (1051.7 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Oct 20, 2019

2019-10-20 12:03:13: antoine changed owner from antoine to stdedos

@totaam
Copy link
Collaborator Author

totaam commented Oct 20, 2019

2019-10-20 12:03:13: antoine edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Oct 20, 2019

2019-10-20 12:03:13: antoine commented


Do you have the client and server output?
If possible, please attach the -d geometry flag to both client and server.

@totaam
Copy link
Collaborator Author

totaam commented Oct 21, 2019

2019-10-21 10:35:49: stdedos uploaded file xpra-client-2457.txt (110.4 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Oct 21, 2019

2019-10-21 10:40:03: stdedos uploaded file display-:20.log (523.2 KiB)

@totaam
Copy link
Collaborator Author

totaam commented Oct 21, 2019

2019-10-21 10:43:37: stdedos commented


I would guess that the "plain" one does not contain anything (many connections and disconnections, I'd assume the files are lost already)

-d geometry is extremely chatty, apologies for that. I am attaching files instead.


Are there "other variables" available at log-file = display-$DISPLAY.log configuration option?

Maybe I'd like to add $timestamp also? Then I could have some history (as long as PC does not shutdown itself, at least)

@totaam
Copy link
Collaborator Author

totaam commented Oct 21, 2019

2019-10-21 21:02:00: stdedos changed owner from stdedos to Antoine Martin

@totaam
Copy link
Collaborator Author

totaam commented Oct 30, 2019

2019-10-30 15:45:45: antoine changed priority from critical to blocker

@totaam
Copy link
Collaborator Author

totaam commented Oct 30, 2019

2019-10-30 15:45:45: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Oct 30, 2019

2019-10-30 15:45:45: antoine changed owner from Antoine Martin to antoine

@totaam
Copy link
Collaborator Author

totaam commented Oct 30, 2019

2019-10-30 15:45:45: antoine commented


According to mailing list: Beta problems some geometry problems are present in 4.0-r24287, but not in 3.0-24039.

@totaam
Copy link
Collaborator Author

totaam commented Nov 3, 2019

2019-11-03 16:21:20: antoine commented


Maybe I'd like to add $timestamp also? Then I could have some history (as long as PC does not shutdown itself, at least)
r24348 adds TIMESTAMP (uppercase to keep things more consistent)

As for the geometry bug:

  • the xterm window is created as (server side):
initial X11 position and size: requested((0, 0, 499, 316), {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)})=(0, 0, 499, 316)
setup() hints={'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)} size=499x316
calc_constrained_size(499, 316, {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)})=(499, 316) (size_constraints=(0, 0, 32767, 32767))
setup() resizing windows to 499x316
  • the client creates it, but the geometry gets rounded down for some reason:
process_new_common: wid=1, OR=False, geometry([0, 0, 499, 316])=(0, 0, 499, 316) / (499, 316)
['configure-window', 1, 211, 245, 495, 305, {'encodings.rg..]}, 'encoding.send-window-size': True, 'encoding.scrolling': True}, 0, {'focused': True}, False, 1, (1080, 1920), []]
configure event: current size=(499, 316), new size=(495, 305), backing=gtk3.CairoBacking(<cairo.ImageSurface object at 0x00000000253284f0>), iconified=False
  • then when we move it, the server processes the configure packet:
_process_configure_window([1, 216, 253, 495, 305, {}, 0, {}, False, 1, (395, 236), ()]) old window geometry: (211, 245, 495, 305)
_update_client_geometry: using owner=DesktopManager(1) (setup_done=True)
_do_update_client_geometry: allocated 495x305 (from <function WindowModel._update_client_geometry.<locals>.window_size at 0x7f939fa52170>)
calc_constrained_size(495, 305, {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (194, 55)})=(493, 303) (size_constraints=(194, 55, 32767, 32767))
_do_update_client_geometry: size({'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (194, 55)})=493x303

and the downward spiral begins.
Turning off the size apply_maxsize_hints workaround using XPRA_WIN32_GEOMETRY=0 does not help. (flag renamed to XPRA_WIN32_MAX_SIZE_HINT in r24356)

With r24357:

  • on Linux (OK):
apply_geometry_hints({b'min_width': 25, b'min_height': 17, b'base_width': 19, b'base_height': 4, b'width_inc': 6, b'height_inc': 13, b'max_width': 32767, b'max_height': 32764}) geometry=<Gdk.Geometry object at 0x7fa258cfde90 (void at 0x557d7dea1f40)>, \
    hints=<flags GDK_HINT_MIN_SIZE | GDK_HINT_MAX_SIZE | GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC of type Gdk.WindowHints>
  • on win32 (NOK):
apply_geometry_hints({b'base_width': 19, b'base_height': 4, b'width_inc': 6, b'height_inc': 13}) geometry=<Gdk.Geometry object at 0x0000000025598db0 (void at 0x00000000242ec7b0)>, hints=<flags GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC of type Gdk.WindowHints>

Differences are expected (ie: we can't set the max-size on win32 because then the maximize buttons end up greyed out)
My guess is that this is a GTK3 bug, maybe it is taking into account the window borders or something.
The new window size is smaller by 4x11.

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 14:53:41: antoine commented


I thought it might be related to the wayland changes in r23305 (#2243), but using the window geometry gives the same / similar result.

r24377 adds a simple test gtk window script.

  • running it on Linux X11, we get exactly the same geometry from the configure event as we get when querying the drawing area, which is also the size that the window originally requested (499x316) - all is well:
event geometry:        (0, 64, 499, 316)
drawing area geometry: (0, 64, 499, 316)
event geometry:        (170, 67, 499, 316)
drawing area geometry: (170, 67, 499, 316)
  • on win32, we get something else, twice... hence the problem.
event geometry:        (37, 37, 547, 394)
drawing area geometry: (63, 97, 495, 305)
event geometry:        (37, 37, 547, 394)
drawing area geometry: (63, 97, 495, 305)
  • on wayland (via weston), we also get an invalid geometry! The same values as win32, as a "bonus" we also get a completely whacky geometry for the first event:
event geometry:        (0, 0, 599, 446)
drawing area geometry: (26, 60, 495, 305)
event geometry:        (0, 0, 547, 394)
drawing area geometry: (26, 60, 495, 305)

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 15:39:44: antoine commented


Confirmed as a GTK3 bug: 24378 + 24379 allows us to run the test script with both python2 / gtk2 and python3 / gtk3.
The problematic values only occur with GTK3, on Wayland and win32.
I'm really not sure how to fix this. We rely on the toolkit for the geometry, buggy geometry breaks everything.

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 16:09:23: stdedos commented


Can we temporarily hardwire the GTK version for the v4.0 branch? Or: Which "most up-to-date" client does not use GTK3? is it "Xpra-Python2-x86_64_3.0.2-24303.zip" this one?

The problematic values only occur with GTK3, on Wayland and win32.

I am not on Wayland (I think), since I have Ubuntu 16.04.6?
So, why am I affected? Or is it GTK3 AND (Wayland OR WIN32)?

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 16:35:09: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 16:35:09: antoine changed owner from antoine to stdedos

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 16:35:09: antoine commented


Fixed in r24380, backport in 24381: GTK3 requires a widget to apply the window size hints correctly.
The test script has also been updated to return the correct values.

@stdedos: there are 4.0 and 3.0.2 mswindows beta builds with this fix here: [https://xpra.org/beta/windows].
Please close if that works for you.

@totaam
Copy link
Collaborator Author

totaam commented Nov 4, 2019

2019-11-04 16:37:01: antoine commented


Which "most up-to-date" client does not use GTK3?
The python2 builds use GTK2.
The python3 builds use GTK3.
We have no choice there.

So, why am I affected?
Because your mswindows client uses GTK3:

Xpra GTK3 client version 4.0-24195 64-bit

Python3 + GTK3 is the new default since version 3.

@totaam
Copy link
Collaborator Author

totaam commented Nov 6, 2019

2019-11-06 14:56:31: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Nov 6, 2019

2019-11-06 14:56:31: antoine set resolution to fixed

@totaam
Copy link
Collaborator Author

totaam commented Nov 6, 2019

2019-11-06 14:56:31: antoine commented


3.0.2 has been released with this fix.

There is now a similar ticket for window position: #2475.

@totaam totaam closed this as completed Nov 6, 2019
@totaam
Copy link
Collaborator Author

totaam commented Nov 7, 2019

2019-11-07 07:41:19: antoine commented


It's interesting to note that Gtk.Window.set_geometry_hints documentation states that: Since 3.20 this argument is ignored and GTK behaves as if None was set.

@totaam
Copy link
Collaborator Author

totaam commented Nov 7, 2019

2019-11-07 15:13:16: antoine commented


Fixed properly in r24403, see #2475#comment:12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant