Xpra: Ticket #919: frame extents synchronization

Split from #885 where most of the work was done in time for 0.15. Related to #794 and #775.

The spec:

As of r9953, we expose all the frame attributes via xpra info, and they should also be set on the root window (as defaults) and on the window itself.

How to check:



Fri, 17 Jul 2015 03:32:19 GMT - Antoine Martin: owner changed

r9955 adds the "frame" debug logging flag which makes it much easier to figure out what is going on server side and with Linux clients. So now you can see the values used by X11 clients:

$ xpra attach -d frame
...
setup_frame_request_windows() window=0x3200056
...
get_window_frame_size(0, 0, 200, 200)=None
get_frame_extents(Xpra-FRAME_EXTENTS)=[0, 0, 37, 0]
get_window_frame_sizes()={'frame': [0, 0, 37, 0], 'offset': (0, 37)}
...
request_frame_extents(GLClientWindow(1 : None)) xid=0x32000d2
get_window_frame_size(37, 71, 499, 316)=None
get_frame_extents(antoine@desktop:~/projects/Xpra/trunk/src on desktop)=[0, 0, 37, 0]

And server side:

sync_frame: frame(0x600022)=None
sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x600022
...
parse_hello_ui_window_settings: client window_frame_sizes={'frame': [0, 0, 37, 0], 'offset': [0, 37]}
set_default_frame_extents([0, 0, 37, 0])
sync_frame: frame(0x600022)=None
sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 37, 0] on 0x600022
sync_frame: frame(0x600022)=(0, 0, 37, 0)
sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 37, 0) on 0x600022

Note: we initially set the frame extents to (0, 0, 0, 0) before the first client connects - that's because we have to set something... and we have no idea what values the client will be using, I guess we could provide a global server-side default somewhere. No big deal I think.

We can check the "default" frame using:

$ xprop -root | grep -i DEFAULT_NET_FRAME
DEFAULT_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 37, 0

We can check individual window frames with:

(which also logs the client supplied frame sizes)

You can get the WINDOWID from the log messages (ie: "0x600022" above) or from:

$ xpra info | egrep "\.title=|xid="
window[1].title=antoine@desktop:~/projects/Xpra/trunk/src
window[1].xid=0x600022

Thu, 17 Sep 2015 15:46:10 GMT - Antoine Martin:

@afarr: how to test: run NativeGUI_info.exe on win32 and NativeGUI_info on osx with different DPI and screen settings to see if the values change, if they do then please re-assign to me so that I can ensure we update the values when the screen configuration changes. (only just thought about this possibility) Having a record of those values will also be useful. Feel free to also verify that the windows have the correct attributes set as per comment:1.


Wed, 14 Oct 2015 01:11:53 GMT - alas:

Testing with windows 8.1 0.16.0 r10783 (and your osx 0.16.0 r10828) clients against fedora 21 0.16.0 r10786.

Running NativeGUI_info.exe with default settings for a 4K display and a laughably low resolution second monitor -

2015-10-13 15:31:00,392 xpra gtk2 client version 0.16.0-r10783
2015-10-13 15:31:01,127 OpenGL_accelerate module loaded
2015-10-13 15:31:01,220  detected keyboard: layout=us
2015-10-13 15:31:01,237  desktop size is 5120x2160 with 1 screen(s):
2015-10-13 15:31:01,239   Default (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-10-13 15:31:01,240     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 5120x2120
2015-10-13 15:31:01,240     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 5120x2120
2015-10-13 15:31:01,482 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10786

I get values that look expected:

C:\Program Files (x86)\Xpra>NativeGUI_info.exe
* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi                              : 96
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 5120, 2120)
* workareas                        : [(0, 0, 3840, 2120), (0, 0, 1280, 680)]

I then used control panel slider to set to a resolution of 1920x1080 on the main display, which was immediately picked up and output client side:

2015-10-13 15:37:25,634 sending updated screen size to server: 3200x1080 with 1 screens
2015-10-13 15:37:25,638   Default (846x285 mm - DPI: 96x96) workarea: 3200x1040
2015-10-13 15:37:25,641     DISPLAY1 1920x1080 at 1280x0 (621x341 mm - DPI: 78x80) workarea: 3200x1040
2015-10-13 15:37:25,644     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 3200x1040
2015-10-13 15:37:25,645 screen size change: will reinit the windows

After which NativeGUI_info.exe again outputs what looks like it should be expected:

changing display to 1920x1080:
C:\Program Files (x86)\Xpra>NativeGUI_info.exe
* antialias.contrast               : 1200
* antialias.enabled                : True
* antialias.hinting                : True
* antialias.orientation            : RGB
* antialias.type                   : ClearType
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (4, 4)
* double_click.time                : 500
* dpi                              : 96
* dpi.x                            : 96
* dpi.y                            : 96
* fixed_cursor_size                : (32, 32)
* icon_size                        : 16
* native_notifiers                 : ['Win32_Notifier']
* native_system_trays              : ['Win32Tray']
* native_tray_menu_helpers         : []
* native_trays                     : ['Win32Tray']
* system_bell                      : system_bell
* vertical-refresh                 : 29
* window_frame.border              : 1
* window_frame.caption             : 23
* window_frame.fixed               : (3, 3)
* window_frame.frame               : (8, 8, 31, 8)
* window_frame.menu-bar            : 20
* window_frame.minimum             : (140, 39)
* window_frame.normal              : (8, 8)
* window_frame.offset              : (8, 31)
* workarea                         : (0, 0, 3200, 1040)
* workareas                        : [(0, 0, 1920, 1040), (0, 0, 1280, 680)]

When I run NativeGUI_info on the OSX client, however... it's not so happy:

Schadenfreude:Helpers Schadenfreude$ ./NativeGUI_info
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/platform/gui.py", line 212, in main
ImportError: No module named x11.bindings

Client-side:

2015-10-13 15:57:31,821 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,055 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10786
2015-10-13 15:57:32,071 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)
2015-10-13 15:57:32,101 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,117 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,117 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,132 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,148 get_window_frame_size(1592, 312, 499, 316)=None
2015-10-13 15:57:32,148 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}
2015-10-13 15:57:32,148 get_window_frame_size(1618, 338, 499, 316)=None
2015-10-13 15:57:32,148 get_window_frame_sizes()={'caption': 23, 'minimum': (140, 39), 'menu-bar': 20, 'normal': (8, 8), 'frame': (8, 8, 31, 8), 'fixed': (3, 3), 'bo
rder': 1, 'offset': (8, 31)}

And server-side:

2015-10-13 15:57:52,145 parse_hello_ui_window_settings: client window_frame_sizes={'menu-bar': 20, 'normal': [8, 8], 'frame': [8, 8, 31, 8],    'caption': 23, 'minimum': [140, 39], 'offset': [8, 31], 'fixed': [3, 3], 'border': 1}
2015-10-13 15:57:52,145 set_default_frame_extents([8, 8, 31, 8])
2015-10-13 15:57:52,146 sync_frame: frame(0x600022)=None
2015-10-13 15:57:52,146 sync_frame: setting _NET_FRAME_EXTENTS=[8, 8, 31, 8] on 0x600022
2015-10-13 15:57:52,147 sync_frame: frame(0x800022)=None
2015-10-13 15:57:52,147 sync_frame: setting _NET_FRAME_EXTENTS=[8, 8, 31, 8] on 0x800022
2015-10-13 15:57:52,183 DPI set to 96 x 96
2015-10-13 15:57:52,261 sync_frame: frame(0x600022)=(8, 8, 31, 8)
2015-10-13 15:57:52,261 sync_frame: setting _NET_FRAME_EXTENTS=(8, 8, 31, 8) on 0x600022
2015-10-13 15:57:52,263 sync_frame: frame(0x800022)=(8, 8, 31, 8)
2015-10-13 15:57:52,264 sync_frame: setting _NET_FRAME_EXTENTS=(8, 8, 31, 8) on 0x800022

Oddly, I found that there were no changes as I moved windows around, re-sized, or used xterms to spawn other applications - perhaps I'm just misinterpreting the use of FRAME in this context though (perhaps this is just outputting initial frame sizes and locations?).

Likewise, when I used xpra info to sift for frames and titles, I got the same output no matter what I did in the way of moving or re-sizing the windows (even if I re-sized the chromium window drastically to window[3].size=(2786, 2081):

[tlaloc@jimador ~]$ xpra info :13 | egrep "\.title=|\.frame="
client.window.frame-sizes.frame=(8, 8, 31, 8)
window[1].frame=(8, 8, 31, 8)
window[1].title=tlaloc@jimador:/usr/bin
window[2].frame=(8, 8, 31, 8)
window[2].title=tlaloc@jimador:~
window[3].frame=(8, 8, 31, 8)
window[3].title=New Tab - Chromium

I also got the same xprop -id values, whatever I did:

[tlaloc@jimador ~]$ xprop -id 0xc00001 -display :13 | grep FRAME
_NET_FRAME_EXTENTS(CARDINAL) = 8, 8, 31, 8

And, disconnecting then re-starting the server, I get nothing from xprop -root:

[tlaloc@jimador ~]$ xprop -root -display :13 | grep -i DEFAULT_NET_FRAME
[tlaloc@jimador ~]$

After connecting, and after then disconnecting a client, I get the same DEFAULT_NET_FRAME_EXTENTS(CARDINAL) = 8, 8, 31, 8 whatever I do.


Wed, 14 Oct 2015 01:20:10 GMT - alas: owner changed

One last detail - connecting with -d frame with my osx client is producing slightly different output (probably reflective of the initial positioning and default sizes of the frames?):

Client connection display info output:

2015-10-13 18:13:31,467  desktop size is 2960x2490 with 1 screen(s):
2015-10-13 18:13:31,468   schadenfreude.local (1044x878 mm - DPI: 72x72)
2015-10-13 18:13:31,468     monitor 1 1680x1050 at 1280x1440 (592x370 mm - DPI: 72x72)
2015-10-13 18:13:31,468     monitor 2 2560x1440 (903x508 mm - DPI: 72x72)

Client-side log output:

2015-10-13 18:13:31,481 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}
2015-10-13 18:13:31,574 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0-r10786
2015-10-13 18:13:31,586 Attached to tcp:10.0.32.136:2200 (press Control-C to detach)
2015-10-13 18:13:31,641 get_window_frame_size(0, 22, 499, 316)=None
2015-10-13 18:13:31,641 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}
2015-10-13 18:13:31,642 get_window_frame_size(0, 22, 499, 316)=None
2015-10-13 18:13:31,642 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)}

Server-side:

2015-10-13 18:13:22,282 sync_frame: frame(0x800022)=None
2015-10-13 18:13:22,283 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x800022
2015-10-13 18:13:22,288 sync_frame: frame(0x600022)=None
2015-10-13 18:13:22,288 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x600022
...
2015-10-13 18:13:32,250 parse_hello_ui_window_settings: client window_frame_sizes={'frame': [0, 0, 22, 0], 'offset': [0, 22]}
2015-10-13 18:13:32,250 set_default_frame_extents([0, 0, 22, 0])
2015-10-13 18:13:32,251 sync_frame: frame(0x800022)=None
2015-10-13 18:13:32,251 sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 22, 0] on 0x800022
2015-10-13 18:13:32,251 sync_frame: frame(0x600022)=None
2015-10-13 18:13:32,252 sync_frame: setting _NET_FRAME_EXTENTS=[0, 0, 22, 0] on 0x600022
2015-10-13 18:13:32,304 DPI set to 72 x 72
2015-10-13 18:13:32,337 sync_frame: frame(0x800022)=(0, 0, 22, 0)
2015-10-13 18:13:32,337 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 22, 0) on 0x800022
2015-10-13 18:13:32,339 sync_frame: frame(0x600022)=(0, 0, 22, 0)
2015-10-13 18:13:32,339 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 22, 0) on 0x600022

On the whole though, except for that OSX traceback... it looks like it's outputting what I'm expecting, so I'll pass it back to you.


Wed, 14 Oct 2015 05:01:49 GMT - Antoine Martin: owner changed

Interesting to see that MS Windows uses the same window frame size with high and low DPI displays. Does the value change on OSX when you change resolutions / DPI? I am also getting (0, 0, 22, 0) in my OSX 10.5.8 build VM. Thanks for the OSX stacktrace, this is fixed in r10833.

Oddly, I found that there were no changes as I moved windows around, re-sized, or used xterms to spawn other applications - perhaps I'm just misinterpreting the use of FRAME in this context though (perhaps this is just outputting initial frame sizes and locations?).


The frame size is the the width and height of the frame around our window: aka the "decorations". This includes the height of the title bar (if present) and window borders. This size should be the same whether the windows are small or big. Moving the window does not usually change the size of those decorations... It may change with DPI, and if we were "per monitor DPI aware" it may change when moving to a monitor with a different DPI setting (Windows 8.1 and later only) - TBC.


See ticket:976#comment:15O :


Fri, 23 Oct 2015 22:22:25 GMT - alas: owner changed

With OSX client 0.16.0 r10972 (your repo) installed, running NativeGui_info, I'm no longer getting tracebacks, but I'm not seeing any difference in results when I use System Preferences to change screen resolutions... in fact it's still not seeming to grab any info for workarea.

With a variety of screen resolution settings, changing none, or one, or both monitor resolutions... I get this same result every time:

Schadenfreude:Helpers Schadenfreude$ ./NativeGUI_info
* cursor_size                      : -1
* desktop_names                    : []
* desktops                         : 1
* double_click.distance            : (-1, -1)
* double_click.time                : 480
* dpi.x                            : -1
* dpi.y                            : -1
* fixed_cursor_size                : (-1, -1)
* icon_size                        : 16
* native_notifiers                 : []
* native_system_trays              : []
* native_tray_menu_helpers         : ['getOSXMenuHelper']
* native_trays                     : ['OSXTray']
* system_bell                      : system_bell
* vertical-refresh                 : -1
* window_frame.frame               : (0, 0, 22, 0)
* window_frame.offset              : (0, 22)
* workarea                         :
* workareas                        : []

Connecting with -d frame seems to give same values as above, as well as a lot of tracebacks recorded in #1010.

Since I assume the workarea(s) shouldn't be blank, I'll assign back to you to look at.


Sat, 24 Oct 2015 02:53:26 GMT - Antoine Martin: status changed

The workarea detection does not exist in OSX, so we don't populate it. Anyway, this would belong in a different ticket - this ticket is only about frame extents.

I will need a Windows >= 8.1 system to fix the "dpi awareness" code.


Sun, 08 Nov 2015 15:37:26 GMT - Antoine Martin: owner, status changed

Note: r11151 fixes windows 8.1 onwards "DPI awareness".


Fri, 13 Nov 2015 04:20:09 GMT - Antoine Martin:

Some of the data in this ticket may not be correct (done without logging out and logging back in with win32).

The correct and up to date information on DPI is now being moved to trac/wiki/DPI


Wed, 09 Dec 2015 01:56:40 GMT - alas:

trac/wiki/DPI/Data now has the NativeGUI_info.exe window_frame data for windows 7 and 8.1 (with a small variety of displays).

"DPI awareness", however, doesn't seem to be changing any output (though, XPRA_DPI_AWARENESS=1 or =2 probably isn't being caught by NativeGUI_info.exe, and window_frame stuff isn't captured with /usr/lib64/python2.7/site-packages/xpra/platform/gui.py, so I'm not sure where else to look for the effects).

I'll do another run through the osx, but I don't think the frame info was changing at all last time I went through.


Mon, 11 Jan 2016 21:16:04 GMT - alas:

Went through Frame Sizes listed with NativeGUI_info on OSX — and discovered that it is the same no matter what sort of monitor is used, how many monitors, what the scaling is set to (even logged out to test in case I was missing fine print there).

Tested with 0.16.1 r11604 osx client, osx 10.9.5 and 10.10.4.

Added the limited data gleaned to trac/wiki/DPI.

I think this ticket is ready to be re-closed - passing it to you Antoine to see if there's anything I've missed.


Mon, 11 Jan 2016 21:16:42 GMT - alas: owner changed


Tue, 12 Jan 2016 01:49:39 GMT - Antoine Martin: status changed; resolution set

See also: bug in compiz #1279


Wed, 03 Oct 2018 06:40:23 GMT - Antoine Martin:

As of r20594, we can disable frame extents with:

XPRA_FRAME_EXTENTS=0 xpra ...

Sat, 23 Jan 2021 05:09:47 GMT - migration script:

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