Xpra: Ticket #2618: gnome-terminal sides not rendered fully

May be related to #2526

When gnome-terminal is maximized, it seems that right and bottom lines are a "transparency graveyard": whatever was rendered above or below that region, will stay there.

Also for some weird reason, in vim, the line (in which you write e.g. :w) is rendered UNDERNEATH the ~/Documents/... path (??)

Executing libre-office (from the same session) renders fully and normally.

"Xpra-Python3-x86_64_4.0-r25468\xpra_cmd" attach ssh://user@ip/10 --ssh="plink -ssh -agent"
2020-03-03 22:19:26,655 Xpra GTK3 client version 4.0-r25468 64-bit
2020-03-03 22:19:26,657  running on Microsoft Windows 10
2020-03-03 22:19:26,743 Warning: failed to import opencv:
2020-03-03 22:19:26,744  No module named 'cv2'
2020-03-03 22:19:26,744  webcam forwarding is disabled
2020-03-03 22:19:30,693 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-03-03 22:19:30,940 keyboard layout code 0x409
2020-03-03 22:19:30,941 identified as 'United States - English' : us
2020-03-03 22:19:31,091 OpenGL_accelerate module loaded
2020-03-03 22:19:31,133 Using accelerated ArrayDatatype
2020-03-03 22:19:31,760 Warning: vendor 'Intel' is greylisted,
2020-03-03 22:19:31,761  you may want to turn off OpenGL if you encounter bugs
2020-03-03 22:19:31,773 OpenGL enabled with Intel(R) HD Graphics 4000
2020-03-03 22:19:35,111  keyboard settings: layout=us
2020-03-03 22:19:35,115  desktop size is 1600x900 with 1 screen:
2020-03-03 22:19:35,116   Default (423x238 mm - DPI: 96x96) workarea: 1600x860
2020-03-03 22:19:35,117     (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131)
2020-03-03 22:19:52,195 enabled remote logging
2020-03-03 22:19:52,202 Xpra GTK3 X11 server version 3.0.6-r25174 64-bit
2020-03-03 22:19:52,205  running on Linux Ubuntu 16.04 xenial
2020-03-03 22:19:52,223 Attached to
2020-03-03 22:19:52,227  (press Control-C to detach)
2020-03-03 22:19:53,846 sound output using 'opus' audio codec
(xpra_cmd:10236): Pango-WARNING **: 22:19:54.289: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-03-03 22:19:55,314 UI thread is now blocked
2020-03-03 22:19:55,656 UI thread is running again, resuming
2020-03-03 22:21:19,678 unknown string message: 0xc2a2 / 0x0 / 0x0
2020-03-03 22:22:04,035 unknown string message: 0xc26a / 0x0 / 0x0
2020-03-03 22:22:23,516 unknown string message: 0xc26a / 0x0 / 0x0
2020-03-03 23:10:29,098 UI thread is now blocked
2020-03-03 23:10:29,180 UI thread is running again, resuming
2020-03-03 23:22:40,404 server is not responding, drawing spinners over the windows
2020-03-03 23:22:41,419 server is OK again

I think I have a ticket like that already open somewhere, but I cannot find it. With this build it's worse.

Tue, 03 Mar 2020 21:26:05 GMT - stdedos: attachment set

Tue, 03 Mar 2020 21:28:36 GMT - stdedos:

This image shows it better: Vivaldi on the background

Tue, 03 Mar 2020 21:28:49 GMT - stdedos: attachment set

Wed, 04 Mar 2020 05:12:28 GMT - Antoine Martin: owner, description changed

Please attach xpra info for the session containing those windows.

My guess is that the window uses size hints to force the window to resize in multiples of the character height / width. But this may not be handled well by GTK3 on windows. (removed clipboard messages from the log output as those are not relevant)

Thu, 05 Mar 2020 08:28:07 GMT - stdedos: attachment set

Thu, 05 Mar 2020 08:31:03 GMT - stdedos:

Xpra info attached, with screenshot fixed (#2621).

Please note that the gnome-terminal is in maximized state, but the window position/size is "shrinked" inwards. (replicate with: open and close a tab in gnome-terminal - Ctrl+Shift+T/Ctrl+Shift+W)

Thu, 19 Mar 2020 14:17:32 GMT - stdedos: owner changed

Also, the issue is much more obvious (related to size hints discussed in some other ticket (#2526?)) if you shrink the font size a lot.

Thu, 19 Mar 2020 14:49:23 GMT - Antoine Martin: owner, status, milestone changed

I can reproduce by changing the terminal font size. (see also #2526 - closed as duplicate)

This is caused by GTK3 not honouring window size hints properly: terminals set size increments matching the font size.

We probably should clear the window at least once following a resize. (but too late for 4.0)

Sat, 09 May 2020 04:44:43 GMT - Antoine Martin: priority changed

Geometry related tickets: #2455, #2516, #2600, #1941.

Sat, 12 Sep 2020 15:44:57 GMT - Antoine Martin:

The translate part of r16229 seems to be causing problems, at least on win32 with a miximized xterm and a screen size that isn't a multiple of the font-size + base-size. That's because the offset is not taken into account when we request a redraw of the window. A temporary workaround is to set:


But that's not ideal.

Sat, 12 Sep 2020 15:59:19 GMT - Antoine Martin: priority changed

This is likely to be related to #2516. The bug goes away after reverting the first chunk of r23459, but the problem is that this was needed for fixing #1339 / #1874? Or can we get by with just the pointer offsets? There also seems to be some redundancy between the window's window_offset and the backing's offset... leading to much confusion, and maybe some synchronization issues or miscalculations?

Mon, 21 Sep 2020 14:49:14 GMT - Antoine Martin: owner, status changed

Clarifying the two offsets. They are related, usually set in the same place (center_backing), and often to the same value.

The client window's window_offset is the delta between the location of the window requested by the server and where we actually end up mapping it on the client. Typically: when we reposition an OR window to ensure it is visible on screen, or when we use padding around a fixed sized window when it is maximized or fullscreen.

It is set from:

It is taken into account in:

The window backing's offset is how much padding we have between the window frame and the drawing area where we paint the window contents.

It is set from:

It is used in:

Based on this, I believe that r27519 is correct. (backporting will be harder!)

@stdedos: does that fix things for you? (updated win32 beta builds with this fix are available) Sorry it's taken so long to identify the bug!

Mon, 21 Sep 2020 15:15:03 GMT - stdedos:

Replying to Antoine Martin:

Based on this, I believe that r27519 is correct. (backporting will be harder!)

Client-only fix? No need to backport for Windows (for me), as the portable builds + argparse configuration fits very nicely into my workflow.

@stdedos: does that fix things for you? (updated win32 beta builds with this fix are available) Sorry it's taken so long to identify the bug!

I have been seeing that specific code piece for a while now - no wonder it took so much time to figure it out. However, I wouldn't call it a blocker per se ... sure, it looks a bit weird, but that's about it - an aesthetical bug.

I can try it tomorrow by playing with the font size - however, otherwise, I don't remember having seen it recently.

Tue, 22 Sep 2020 08:57:16 GMT - stdedos:

The window still behaves weirdly when changing the font size. While maximized:

I could accept though, that both of these issues are not "fixed-size windows receive incomplete repaints"

Mon, 28 Dec 2020 14:44:41 GMT - Antoine Martin: owner, status, milestone changed

Sat, 23 Jan 2021 05:56:10 GMT - migration script:

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