Xpra: Ticket #1086: improve DPI, anti-aliasing, colour management

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.

Wed, 16 Mar 2016 05:57:42 GMT - Antoine Martin: status, milestone changed

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed

Thu, 22 Sep 2016 10:26:29 GMT - Antoine Martin:

OSX links here:

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.

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).

Thu, 22 Sep 2016 15:11:55 GMT - Antoine Martin: owner, status changed

A lot of these changes should have been recorded in #1155 - oh well:

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):

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:

Wed, 16 Nov 2016 02:15:24 GMT - alas: owner changed

Tested a bit with 1.0 r14155 osx client (pre-dylib errors) alone & with 1.0 r14430 fedora 23 server.

I'll attach a log of the xprop -root _ICC_PROFILE and the NativeGUI_info for examination...

Wed, 16 Nov 2016 02:16:43 GMT - alas: attachment set

NativeGUI_info for 1.0 r14155

Wed, 16 Nov 2016 02:17:22 GMT - alas: attachment set

xprop ICC info server side

Fri, 18 Nov 2016 14:44:51 GMT - Antoine Martin: owner changed

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?

Sat, 19 Nov 2016 01:51:39 GMT - alas: attachment set

display arrangement

Sat, 19 Nov 2016 01:59:08 GMT - alas: owner changed

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.

display arrangement

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?

Sat, 19 Nov 2016 17:38:17 GMT - Antoine Martin: owner changed

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)

Mon, 21 Nov 2016 19:35:21 GMT - alas: owner changed

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.

Mon, 21 Nov 2016 19:36:13 GMT - alas: attachment set

NativeGUI_info with retina at "default"

Mon, 21 Nov 2016 19:36:55 GMT - alas: attachment set

NativeGUI_info at More Space resolution

Tue, 22 Nov 2016 09:51:53 GMT - Antoine Martin: status changed; resolution set

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..

Tue, 22 Nov 2016 14:03:39 GMT - Antoine Martin: summary changed

Tue, 07 Feb 2017 02:21:33 GMT - Antoine Martin:

As per this chromium ticket: Support for retreiving the monitor color space on X11.

Thu, 23 Feb 2017 10:28:29 GMT - Antoine Martin:

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.

Wed, 01 Mar 2017 00:30:43 GMT - alas: attachment set

display (triple) set up

Wed, 01 Mar 2017 00:31:10 GMT - alas: attachment set

NativeGUI_info with 2.0 r15170 osx client

Wed, 01 Mar 2017 00:37:25 GMT - alas:

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.

display (triple) set up

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

Wed, 01 Mar 2017 10:42:53 GMT - Antoine Martin:

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.

Sat, 07 Jul 2018 06:26:38 GMT - Antoine Martin:

Apple killed off subpixel antialiasing in 10.14 and called it a “refinement”. Not sure they know what that word means

Sat, 23 Jan 2021 05:14:35 GMT - migration script:

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