xpra icon
Bug tracker and wiki

Opened 9 months ago

Last modified 2 months ago

#2618 new defect

gnome-terminal sides not rendered fully

Reported by: stdedos Owned by: stdedos
Priority: blocker Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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 172.16.57.121:22
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.

Attachments (3)

xpra-gnome-terminal_partial-rendering.png (21.8 KB) - added by stdedos 9 months ago.
xpra-gnome-terminal_partial-rendering-2.png (85.9 KB) - added by stdedos 9 months ago.
xpra-2618-info.zip (222.3 KB) - added by stdedos 9 months ago.

Download all attachments as: .zip

Change History (14)

Changed 9 months ago by stdedos

comment:1 Changed 9 months ago by stdedos

This image shows it better: Vivaldi on the background

Changed 9 months ago by stdedos

comment:2 Changed 9 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to stdedos

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)

Changed 9 months ago by stdedos

Attachment: xpra-2618-info.zip added

comment:3 Changed 9 months ago by 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)

comment:4 Changed 9 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

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.

Last edited 9 months ago by stdedos (previous) (diff)

comment:5 Changed 9 months ago by Antoine Martin

Milestone: 4.04.1
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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)

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 7 months ago by Antoine Martin

Priority: majorcritical

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

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 3 months ago by 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:

XPRA_REPAINT_ALL=1

But that's not ideal.

comment:8 Changed 3 months ago by Antoine Martin

Priority: criticalblocker

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?

comment:9 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

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:

  • setup_window for OR windows which then calls calculate_window_offset
  • center_backing

It is taken into account in:

  • do_show_pointer_overlay : when showing a shadow window and another user is moving the pointer (adjusting the pointer coordinates)
  • move_resize so the move portion is relative to the window's current (adjusted) location
  • _offset_pointer so all pointer events are reported relative to where the window is really meant to be

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:

  • center_backing
  • resize where we clear it or call center_backing
  • update_window_state may call center_backing

It is used in:

  • paint_backing_offset_border - to ensure this padding is painted, rather than showing left-overs from a previous offset
  • clip_to_backing - used when we draw
  • cairo_draw to repaint the window at the correct position (does the drawing area always cover the whole window? shouldn't it?)

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!

comment:10 in reply to:  9 Changed 2 months ago by 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.

comment:11 Changed 2 months ago by stdedos

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

  • shrinking the font will move the window center-wise, shrinking it too
  • enlarging the font will make incomplete "cleaning" on the post-offset bottom (at least), but not affect window size.

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

Note: See TracTickets for help on using tickets.