follow up from #697, #559, #163, #976.
We now have fairly complete data from on the wiki: wiki/DPI and wiki/DPI/Data.
OSX needs doing.
Milestone renamed
OSX links here:
NSHighResolutionCapable=true
, but I don't think we need this since we use opengl for rendering?
Somewhat related: Allowing OpenGL applications to utilize the integrated GPU: setting NSSupportsAutomaticGraphicsSwitching=true
allows the application to run on the integrated GPU rather than the discrete one (for laptops with dual gpus) - this saves battery life, but since we're having problems with the intel gpus (#1233, especially on osx: #563) we're not going to enable that.
NSHighResolutionCapable=true
anyway as this shouldn't do any harm and may help when not using opengl rendering?
On my OSX VM, I see a reported DPI of 72x72 for a 1280x1024 screen (but -1 is still shown for DPI and vrefresh using the native gui tool).
A lot of these changes should have been recorded in #1155 - oh well:
_ICC_PROFILE
X11 root window property
I don't think that OSX has any API for querying the anti-aliasing settings, so that's that. As for the DPI on OSX, we can continue to rely on the calculated DPI which is based on the display dimensions - these dimensions should be correct and we have no other option anyway.
Still TODO (may go in a separate ticket so we can close this one):
_ICC_PROFILE_N
This ticket is now tracking a bit more than just dpi and anti-alias stuff, for lack of a better place...
@afarr: things to test:
xprop -root _ICC_PROFILE
should show the exact same value on client and server, more details using "-d screen"
xprop -root _NET_WORKAREA
- this helps application place their windows in the right place (ie: not overlapping the dock or top menu)
Tested a bit with 1.0 r14155 osx client (pre-dylib errors) alone & with 1.0 r14430 fedora 23 server.
xprop -root _NET_WORKAREA
run server side is exactly what I'd expect.
I'll attach a log of the xprop -root _ICC_PROFILE
and the NativeGUI_info for examination...
NativeGUI_info for 1.0 r14155
xprop ICC info server side
but it looks like it's outputting details for every potential dpi setting for each display
Not exactly: OSX has the concept of "active", "online" and "main" displays. These sets often contain the same monitors, so they may be listed up to 3 times. And we also lists all the modes supported by each monitor, each time..
xprop and NativeGUI_info are outputting in decimal & hex and so they're not clearly matching
Here's a one liner to convert the xprop output data to hexadecimal:
echo "_ICC_PROFILE(CARDINAL) = 0, 0, 15, 48, 97, 112" | \ python -c 'import sys,binascii;ints=[int(x.strip()) for x in sys.stdin.read().split("=")[1].split(",") if x.strip()];print(binascii.hexlify(bytearray(ints)))'
You can use it directly list this:
xprop -root _ICC_PROFILE | python -c 'import sys,...'
Or better yet, use r14446 or later server-side and you can just run:
python ./xpra/platform/xposix/gui.py
The vrefresh code has not changed, you can get more debug information by running the tool with "-v" or with the XPRA_OSX_DEBUG=1
env var.
-1 means no value.
Let's not worry too much about this one, it isn't used for anything yet.
workarea & workareas seem to correspond ..
They do... but we probably shouldn't be sending negative values to the server as this could mess up window positioning.
This just looks wrong from your attachment:
* workareas : [(0, 4, 1680, 1023), (-880, 1050, 2560, 1417)]
What is the arrangement here? Are they really overlapping?
display arrangement
Ok, using the 10.10.5 osx machine to run 1.0 r14448 against a 1.0 r14449 fedora 23 server... I ran python ./xpra/platform/xposix/gui.py
and compared with the ICC profile from the NativeGUI_info... and the first 12-15 digits matched & so did the last 23... so I'm going to guess that the ones in between did as well.
As for the display arrangement that generated that workarea... 2560x1440 above a 1680x1050 - like so.
My interpretation was that the lower 1680x1050, as the "primary" monitor, was being designated at 0,4,1680,1023 (presumably the 1050 - 27 for bottom menu or something?) ... and that the 2560x1440 was therefore at (1680 - 2560 = -880), 1050 (top dimension of the 1680x1050?), 2560 (actual width?), 1417 (1440 - 23 ... which isn't the same as the above 27, oddly... but close).
So, yeah... it sort of makes sense. Right?
The visibleframe which we use as "workspace" value is the rectangle is always based on the current user-interface settings and does not include the area currently occupied by the dock and menu bar. The reason why the values don't add up is because as per Dealing with multiple screens programming, the coordinate system is upside-down and all relative to the "primary screen". Oh joy.
So as of r14462 we use the same calculations as GTK - which should now match the screen geometry which we also get from GTK (in absolute coordinates, with y axis going down from the top-left corner)
I am unable to test this as any secondary screens added via virtualbox aren't detected by maxosx, and I haven't got the mac mini with me right now (I usually do - damn, just when you need it). But with a single screen, the values make sense: a 1280x1024 screen gives: 0, 22, 1280, 911
which leaves 22 pixels for the menu bar at the top and 91 pixels for the dock at the bottom (both look about right).
@afarr: does this give us more sensible values now for your setup as per above?
Side note: please attach the full output of Native_info -v
which will include the details of the calculations.
Bonus points for running it on a high-dpi display (aka "retina") since this may show a different value for the backingScaleFactor
in verbose mode. (OSX 10.7.x onwards only)
I hope that we're not supposed to use any of the NSScreen because those don't seem to be accessible via pyobjc (tested on OSX 10.9.x)
Well... I wonder what I'm gonna spend all those bonus points on.
Tested with the 1.0 r14467 client. Ran the NativeGUI_info -v
with the same setup as listed above, first with the retina display set at "Default" size:
2016-11-21 11:01:43,007 sending updated screen size to server: 2560x2240 with 1 screens 2016-11-21 11:01:43,007 schadenfreude.local (903x790 mm - DPI: 72x72) 2016-11-21 11:01:43,008 monitor 1 1280x800 at 880x1440 (451x282 mm - DPI: 72x72) workarea: 1280x773 at 880x1463 2016-11-21 11:01:43,008 monitor 2 2560x1440 (903x508 mm - DPI: 72x72) workarea: 2560x1417 at 0x23
And again at "More Space" size:
2016-11-21 11:09:10,434 sending updated screen size to server: 2560x2490 with 1 screens 2016-11-21 11:09:10,435 schadenfreude.local (903x878 mm - DPI: 72x72) 2016-11-21 11:09:10,435 monitor 1 1680x1050 at 880x1440 (592x370 mm - DPI: 72x72) workarea: 1680x1023 at 880x1463 2016-11-21 11:09:10,435 monitor 2 2560x1440 (903x508 mm - DPI: 72x72) workarea: 2560x1417 at 0x23
It does indeed look like the backingScaleFactor=2.0
value is different than the non-retina display (backingScaleFactor=1.0
), but the dimensions listed seem to match the approximations that the System Preferences indicate.
I'll attach both the native infos.
NativeGUI_info with retina at "default"
NativeGUI_info at More Space resolution
r14469 simplifies the code by making the workareas relative to the screen coordinates they're on (then we don't have to care about the relative coordinates, only adjust for the inverted Y axis)
Let's close this for now before we find something else wrong with it..
As per this chromium ticket: Support for retreiving the monitor color space on X11.
The workarea code was wrong and was causing some applications to behave strangely (ie: menus would appear lower than they should). Fixed in r15161, r15162 for v1.0.x branch.
display (triple) set up
NativeGUI_info with 2.0 r15170 osx client
Ran the NativeGUI_info again with the 2.0 r15170 osx client (on 10.12.1, in case that makes a difference).
The output looks similar to before, but without negative values.
I went ahead and attached the output... and a screenshot of what the triple display layout looks like.
Just for comparison sake, connecting to a 2.0 r15189 fedora 25 server, this is the workarea output.
2017-02-28 16:33:01,498 desktop size is 5520x2160 with 1 screen: 2017-02-28 16:33:01,499 schadenfreude.local (1947x762 mm - DPI: 72x72) 2017-02-28 16:33:01,499 monitor 1 1680x1050 at 0x1110 (592x370 mm - DPI: 72x72) workarea: 1680x1023 at 0x23 2017-02-28 16:33:01,499 monitor 2 1600x900 at 80x210 (564x317 mm - DPI: 72x72) workarea: 1600x877 at 0x23 2017-02-28 16:33:01,499 monitor 3 3840x2160 at 1680x0 (1354x762 mm - DPI: 72x72) workarea: 3840x2137 at 0x23 2017-02-28 16:33:01,500 upscaled by 125%, virtual screen size: 4416x1728 2017-02-28 16:33:01,500 schadenfreude.local (1947x762 mm - DPI: 57x57) 2017-02-28 16:33:01,501 monitor 1 1344x840 at 0x888 (592x370 mm - DPI: 57x57) workarea: 1344x818 at 0x18 2017-02-28 16:33:01,501 monitor 2 1280x720 at 64x168 (564x317 mm - DPI: 57x57) workarea: 1280x702 at 0x18 2017-02-28 16:33:01,501 monitor 3 3072x1728 at 1344x0 (1354x762 mm - DPI: 57x57) workarea: 3072x1710 at 0x18
FYI: the workarea code is pretty much useless with multiple monitors because we have a single rectangle value which is supposed to cover all monitors... (see _NET_WORKAREA and multiple monitors), and so in this case we don't set it at all.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1086