xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 3 years ago

Last modified 2 years ago

#163 closed defect (fixed)

pass client DPI preference to server (and use sane defaults of 96dpi)

Reported by: Antoine Martin Owned by: alas
Priority: blocker Milestone: 0.5
Component: core Version: 0.3.2
Keywords: Cc:

Description

As discussed here on the mailing list

We need to calculate the client's screen dimensions and pass it to the server so that the Xvfb uses the same dimensions.

The --dpi option of xrandr actually computes dimensions from the resolution and dpi.

Attachments (19)

dummy-dpi.diff (686 bytes) - added by Antoine Martin 4 years ago.
improved patch: minimize diff
dummy-constant-dpi-option.diff (1.9 KB) - added by Antoine Martin 4 years ago.
same change with an xorg.conf option instead
dummy-constant-dpi-option-ifdefed.diff (1.9 KB) - added by Antoine Martin 4 years ago.
same but with ifdef around randr code so dummy can be built without randr
dummy-constant-dpi-option-ifdefed-constified.diff (2.0 KB) - added by Antoine Martin 4 years ago.
same but constified (cleaner)
dummy-constant-dpi-v2.patch (2.2 KB) - added by Antoine Martin 4 years ago.
updated patch: use the system dpi (comes from DisplaySize? in dummy driver section of xorg.conf and falls back to Xorg -dpi value)
0002-Constant-DPI.patch (2.2 KB) - added by Antoine Martin 4 years ago.
patch as used by the spec files
fedora20-dummy-constant-dpi-specfile.patch (1.0 KB) - added by Antoine Martin 4 years ago.
updated patch with cleaner file context
centos6.5-dummy-constant-dpi-specfile.patch (966 bytes) - added by Antoine Martin 4 years ago.
centos 6.5 patch
dummy-constant-dpi-v3.patch​ (3.3 KB) - added by Antoine Martin 4 years ago.
patch which allows the xDPI and yDPI to be overriden via a root window property
0002-Constant-DPI.2.patch (3.3 KB) - added by Antoine Martin 4 years ago.
updated version of the patch for use with rpm specfiles
fedora19-dummy-constant-dpi-specfile.patch (991 bytes) - added by Antoine Martin 4 years ago.
updated specfile patch for Fedora 19
fedora20-dummy-constant-dpi-specfile.2.patch (1.1 KB) - added by Antoine Martin 4 years ago.
updated specfile patch for Fedora 20
fedora21-dummy-constant-dpi-specfile.patch (1.0 KB) - added by Antoine Martin 4 years ago.
updated specfile patch for Fedora 21
centos6-dummy-constant-dpi-specfile.patch (1.1 KB) - added by Antoine Martin 4 years ago.
updated specfile patch for CentOS 6.x
redhat7-dummy-constant-dpi-specfile.patch (1.0 KB) - added by Antoine Martin 4 years ago.
updated specfile patch for RedHat? 7
dummy_driver.c.whitespaced (19.6 KB) - added by Antoine Martin 4 years ago.
whitespace cleaned up version of the driver
centos7-dummy-constant-dpi-specfile.patch (1005 bytes) - added by Antoine Martin 3 years ago.
spec file patch for centos7
ticket163-DPI_181-xterm.PNG (51.4 KB) - added by alas 3 years ago.
Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content
ticket163_firefox-fullscreen_windows0.15.0-r7847-client.PNG (1.4 MB) - added by alas 3 years ago.
firefox fullscreen on 4K monitor displays mostly "offscreen"

Download all attachments as: .zip

Change History (68)

comment:1 Changed 5 years ago by Antoine Martin

Actually, looking at both Xdummy and Xvfb, I get reasonable values for the dpi:

  • Xdummy:
    $ xrdb -query | grep dpi
    Xft.dpi:        96
    $ xdpyinfo | grep -i dot
      resolution:    37x47 dots per inch
    
  • Xvfb:
    $ xrdb -query | grep dpi
    Xft.dpi:        96
    $ xdpyinfo | grep -i dot
      resolution:    100x100 dots per inch
    

Now, the X11 server DPI reported is not great in the case of Xdummy, but since all the toolkits use the value from xrdb, I'm not sure we should worry too much about this. Even if we did, this 6 year old bug is not getting any response from Xorg...

comment:2 Changed 5 years ago by Antoine Martin

r1175 improves things by always setting the DPI to 96 by default (obviously this can be changed with --xvfb).

The only problem is that despite reporting the correct value with Xdummy in the Xorg server log file:

$ grep -i dpi Xorg.10.log
[  7265.289] (++) DUMMY(0): DPI set to (96, 96)

xdpyinfo still disagrees:

$ xdpyinfo | grep -i dot
  resolution:    30x37 dots per inch

And this is as far as I am willing to go battling xorg API.

comment:3 Changed 5 years ago by Antoine Martin

Note: the Xft.dpi is already sent to the server as part of _XSETTINGS_SETTINGS.

comment:4 Changed 5 years ago by Antoine Martin

Applications known to have problems (which I happen not to use...):

  • emacs
  • konsole

comment:5 Changed 5 years ago by Antoine Martin

Just tested both with trunk at r1255 and the following command lines:

xpra --no-daemon --bind-tcp=0.0.0.0:10000 start :10 \
  '--xvfb=/usr/local/bin/Xorg -nolisten tcp +extension GLX \
  +extension RANDR +extension RENDER \
  -logfile /home/antoine/Xorg.10.log \
  -config /home/antoine/xorg.conf'
DISPLAY=:10 konsole &
DISPLAY=:10 emacs&
xpra attach :10

Both konsole and emacs look fine.


Version info:

$ rpm -qa | egrep -i "konsole|emacs"
xemacs-filesystem-21.5.31-4.fc17.noarch
emacs-24.1-3.fc17.x86_64
konsole-part-4.8.4-1.fc17.x86_64
emacs-common-24.1-3.fc17.x86_64
konsole-4.8.4-1.fc17.x86_64
emacs-filesystem-24.1-3.fc17.x86_64

Here's what I have in my client PC:

$ xdpyinfo | egrep -i "dot|dim"
  dimensions:    2560x1600 pixels (677x423 millimeters)
  resolution:    96x96 dots per inch

And in the xpra server I find:

$ xdpyinfo | egrep -i "dot|dim"
  dimensions:    2560x1600 pixels (2338x584 millimeters)
  resolution:    28x70 dots per inch

The Xft.dpi is identical though:

$ xrdb -query | grep dpi
Xft.dpi:	96
Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 5 years ago by Antoine Martin

As per the mailing list, the clients which exhibit this problem do not have Xft.dpi set to anything.

One can workaround the issue by setting it by hand before connecting with xpra:

echo "Xft.dpi: 96" | xrdb -

comment:7 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

done in r1262

Adds --dpi=NNN option to xpra, and default value of 96 set in the global config file. See changeset commit log for details.

comment:8 Changed 5 years ago by Sergio Callegari

This is still open for me as of xpra 0.7.0

when using xdummy with the default config, I have xdpyinfo returning 20x25 pixels per inch. In spite of the Xft.dpi, this breaks all java apps.

If I modify the xpra setup in etc, to have the xorg.conf including a more reasonable displaysize (e.g. DisplaySize? 508 317) then everything is fine.

comment:9 Changed 5 years ago by Sergio Callegari

Resolution: fixed
Status: closedreopened
Type: enhancementdefect

comment:10 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: reopenedclosed

Thanks, applied in r1983 (will be in 0.7.1)

Note though that this is only a workaround, Java should be honouring the Xft.dpi value. This new display size may be better for your use case, but it may not match everyone's... Would you mind sharing how you got to these values?

comment:11 Changed 5 years ago by Sergio Callegari

Basically, I searched for something giving me a value between 80 and 90 (I get 84 with this). This assures that I get readable fonts and at the same time xpra remote windows get a slightly smaller font that my standard ones, which is nice to quickly distinguish them.

comment:12 Changed 5 years ago by rkfg

I have this issue, too. The problem is that DPI changes after attaching if Virtual option in servers xorg.conf is set too high. The default is 5120 3200. Here's what I have:

Client:

> xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    1920x1080 pixels (508x285 millimeters)
resolution:    96x96 dots per inch

Server before the client attaches:

> DISPLAY=:100 xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    5120x3200 pixels (1355x847 millimeters)
resolution:    96x96 dots per inch

Server after the attaching:

> DISPLAY=:100 xdpyinfo | grep -C 2 "screen #"
number of screens:    1

screen #0:
dimensions:    1920x1080 pixels (1355x847 millimeters)
resolution:    36x32 dots per inch

The display size in xorg.conf on the server side seems to be ignored (though it's set to 508 317 by default) and it's calculated as virtual size divided by resolution and multiplied by physical size or something like that. Setting Virtual to the actual client resolution solves this but can I prevent setting the wrong DPI on attach or is there any other workaround except setting the Virtual size equal to the clients one? Java apps which use Swing become unusable since fonts are unreadable.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:13 Changed 5 years ago by Antoine Martin

I believe that the dpi that we set will be correct, you can verify it with:

xrdb -query | grep dpi

Both before and after the client connects.
Java should not be using the hardware values from Xorg, that's what the X resource database is for.

If you feel very strongly about this bug, feel free to file a bug with your Java distributor.


Some potential workarounds:

  • You may be able to find a version of Java which does not do this (openjdk or other).
  • Start the Java application before the display is resized, so Java will pickup the original dpi.
  • use Xvfb which does not do xrandr and will therefore keep its original dpi, but then you may encounter all sorts of other display anomalies.

comment:14 Changed 5 years ago by rkfg

Yes, xrdb returns the correct dpi but that one from xdpyinfo matters, too. And if you can change it on the fly maybe it's good idea to send the physical display size to the server along with the resolution? I just don't understand why the physical size 508x385 mm changes to 1355x847 mm after the client connects. It should stay the same and the only thing that should change is resolution but instead it seems to use fixed dpi and changing the resolution changes the physical display size which is weird. Of course, there are workarounds like you suggested (I prefer setting virtual size to 1920x1200 hence it's the biggest resolution of all desktops I use) but it would be better to not bother about dpi at all and have it 96 for every resolution regardless of display size. Is what I'm asking not possible at all?

comment:15 Changed 5 years ago by Antoine Martin

You cannot change the physical display size - there is no such api for the dummy driver, and it's very unlikely there will ever be one. Fixing Java on the other hand is relatively easy.

comment:16 Changed 5 years ago by Antoine Martin

Please do report any application that exhibits this problem (with distro and version, etc), I'm not having any issue on Fedora 18 with:

$ java -version
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (fedora-2.3.3.fc18.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

I've tried jedit, josm, etc. If you are having problems, it may be worth trying this JVM.

comment:17 Changed 5 years ago by leuko

I am frequently using old applications written with WindU toolkit which are used by many industrial applications which are developed since ~15 years and somehow conservative regarding GUI.

WindU toolkit appearantly doesn't use the DPI value reported by the Xft.dpi. My xpra client computer has 90 dpi monitors with 3360x1050 pixels which results in unreadable fonts after attaching (connecting) like eureka7 described. My xpra server xorg.conf uses 5120x3200 virtual size.

My workaround is to decrease the virtual option to the resolution which I am using on the client that the DPI calculated by xorg doesn't get a tiny value.

Last edited 5 years ago by leuko (previous) (diff)

comment:18 Changed 5 years ago by Antoine Martin

Note: some Java (and possibly others) application lookup gnome.Xft/DPI instead of Xft.dpi so we now set that value as well since r3034.

To get this used with Java, one also needs to tell Java to use the GTK look and feel, more information here: How to Set the Look and Feel

Note though that I have tested this with jedit and some other apps and did notice any difference...

java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -jar APPJAR

The code in Java that is used to figure out the display size is in XToolkit.java and does this:

public int getScreenResolution() {
        long display = getDisplay();
        awtLock();
        try {
            return (int) ((XlibWrapper.DisplayWidth(display, 
                XlibWrapper.DefaultScreen(display)) * 25.4) /
                    XlibWrapper.DisplayWidthMM(display, 
                XlibWrapper.DefaultScreen(display)));
        } finally {
            awtUnlock();
        }
    }

Making Xlib calls to get the display size... so we cannot do anything about it or override it, the only way to get the X11 server to report the values we want is going to require some changes in Xvfb/Xdummy? (see ticket/189)


Some related info:

comment:19 Changed 5 years ago by Antoine Martin

More applications seem to be affected: they are reading the dpi directly using xlib instead of Xft.dpi, see #347: evince for example.


I'm not convinced that the "-dpi 96" flag we pass to Xorg is particularly useful, with my 2560x1600 monitor I get:

  • with -dpi 96:
    $ xdpyinfo | grep -i dots
    resolution:    48x48 dots per inch
    

(that's because the virtual size we define is Virtual 5120 3200)

  • without it:
    $ xdpyinfo | grep -i dots
    resolution:    128x128 dots per inch
    

Which is a bit closer to what we want, though this will vary: if I switch resolution to 1280x800 I then get:

$ xdpyinfo | grep -i dots
resolution:    64x64 dots per inch

So... without adding randr support to the dummy driver, we cannot satisfy everyone, but I guess that removing "-dpi 96" at least makes it more likely that the dpi will be closer to what we really want?
Feedback welcome.

comment:20 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: closedreopened

comment:21 Changed 4 years ago by Antoine Martin

For applications that query the X11 server directly, r6086 adds support for wiki/FakeXscreenmm.
There are beta RPM builds of the library too.

This works with applications that use XDisplayWidthMM and XDisplayHeightMM but not (yet?) for those that use the macros DisplayWidthMM and DisplayHeightMM as those access the screen object directly... (so the output of xdpyinfo is still wrong for the "resolution" but now correct for the screen dimensions..)
Java applications will still use the wrong value..

I may still remove this feature if I can find a better way to get the right dimensions in the X server, somehow.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:22 Changed 4 years ago by Antoine Martin

Far too few benefits for the costs, so removed in r6091.

Better options:

  • add randr 1.2 support to dummy, as per this patch for Xvfb
  • make the dummy driver call RRScreenSizeNotify with the newly calculated mm values from DUMMYSwitchMode?

comment:23 Changed 4 years ago by Antoine Martin

It took a lot of effort (randr12 support is.. like going down the rabbit hole), but in the end the patch to dummy is rather small and simple!

I will try to add an option for this new dpi mode, then try to get it merged upstream.
It would also be nice to be able to override the dpi value at runtime, which implies looking up the new dpi value somewhere, probably as an X11 property.


Note: these changes should also be very useful with HiDPI displays. (ie: "4K" displays are becoming popular)


Found an old (2003!) X11 discussion, still very relevant: DPI with multiple heads and virtual desktops

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: dummy-dpi.diff added

improved patch: minimize diff

Changed 4 years ago by Antoine Martin

same change with an xorg.conf option instead

Changed 4 years ago by Antoine Martin

same but with ifdef around randr code so dummy can be built without randr

Changed 4 years ago by Antoine Martin

same but constified (cleaner)

Changed 4 years ago by Antoine Martin

Attachment: dummy-constant-dpi-v2.patch added

updated patch: use the system dpi (comes from DisplaySize? in dummy driver section of xorg.conf and falls back to Xorg -dpi value)

comment:24 Changed 4 years ago by Antoine Martin

Sent latest patch to xorg-devel ML: "ConstantDPI" option

Changed 4 years ago by Antoine Martin

Attachment: 0002-Constant-DPI.patch added

patch as used by the spec files

Changed 4 years ago by Antoine Martin

updated patch with cleaner file context

Changed 4 years ago by Antoine Martin

centos 6.5 patch

comment:25 Changed 4 years ago by Antoine Martin

updated dummy packages have been built for all the distros above (centos 6.5, redhat7, fedora 20 and fedora rawhide): http://xpra.org/beta/

Trivial with the patches above, ie: for Fedora 20:

yum install -y yum-utils
yumdownloader --source xorg-x11-drv-dummy
rpm -ivh xorg-x11-drv-dummy*rpm
cd;cd rpmbuild
yum-builddep SPECS/xorg-x11-drv-dummy.spec
patch -p1 < /usr/src/fedora20-dummy-constant-dpi-specfile.patch 
cp /usr/src/0002-Constant-DPI.patch ./SOURCES/
rpmbuild -ba SPECS/xorg-x11-drv-dummy.spec 
Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

patch which allows the xDPI and yDPI to be overriden via a root window property

Changed 4 years ago by Antoine Martin

Attachment: 0002-Constant-DPI.2.patch added

updated version of the patch for use with rpm specfiles

Changed 4 years ago by Antoine Martin

updated specfile patch for Fedora 19

Changed 4 years ago by Antoine Martin

updated specfile patch for Fedora 20

Changed 4 years ago by Antoine Martin

updated specfile patch for Fedora 21

Changed 4 years ago by Antoine Martin

updated specfile patch for CentOS 6.x

Changed 4 years ago by Antoine Martin

updated specfile patch for RedHat? 7

Changed 4 years ago by Antoine Martin

Attachment: dummy_driver.c.whitespaced added

whitespace cleaned up version of the driver

comment:26 Changed 4 years ago by Antoine Martin

Also, on win32 it looks like we may want/need to do more work. See AnandTech: Scaling Windows - The DPI Arms Race: Developers can call SetProcessDpiAwareness to declare that their application is DPI aware, and if so, Windows will not perform any scaling of the application. It’s then up to the application developers to decide how best to handle “non-standard” DPI settings.
We probably want to do that no matter what, since the server is meant to have the same DPI settings the client should not attempt to scale anything.

Also: With the cropped image, you can instantly see that the font that Chrome is using is not scaling very well. Text in Chrome on a High DPI system is very poor, and defeats the purpose of using a high resolution screen since you actually lose fidelity rather than gain it.

And finally: To get around these issues, Microsoft has expanded the DPI API to allow for per-monitor DPI-aware applications. - the operating system will send a WM_DPICHANGED message to the application when most of the application’s area has moved to a display with a different DPI level (in Windows 8.1). We don't have per-display DPI with Xinerama, but we could just set the global DPI instead. I'm just not sure what "most" means in this context.. more than 50% of the pixels? This will need testing on Windows 7 or later with a display DPI > 120.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:27 Changed 3 years ago by Antoine Martin

Note: the spec files are now living in svn here: browser/xpra/trunk/rpmbuild, see #605.

Changed 3 years ago by Antoine Martin

spec file patch for centos7

comment:28 Changed 3 years ago by Antoine Martin

Extra difficulty: it seems that GTK gets confused by rotated displays, as shown here:

desktop size is 4720x3840 with 1 screen(s):
  ':0.0' (1187x965 mm) workarea: 4720x2295  - DPI: 101x101
    DVI-I-1 2560x1600 at 0x735 (646x406 mm - DPI: 100x100)
    DP-1 2160x3840 at 2560x0 (621x341 mm - DPI: 88x286)

The 'DP-1' display is rotated but the dimensions shown are not... and so our DPI calculations are off!
(sadly, also true with GTK3..)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:29 Changed 3 years ago by Antoine Martin

As per Writing DPI-Aware Desktop and Win32 Applications (worth a read), I think we should use SetProcessDpiAwareness(Process_System_DPI_Aware).

Windows 8.1 has the ability to give us per-monitor DPI, and other nice things like Viewing distance incorporated in default DPI calculation (though this one may just obfuscate things), Window notification so we know to adjust DPI for a given window, etc..

Sadly, until X11 also supports per-monitor DPI, this won't be of much use to us.

comment:30 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: reopenednew

OK, I believe that the default "dpi-awareness" is "system-dpi-aware" (and only windows 8.1 onwards make use of the new "dpi-awareness" API, and we only have a single monitor anyway on the X11 server side), so we use the vista-onwards SetProcessDpiAware() API instead in r7747.

afarr: please bear in mind that:

  • you must have the updated dummy drivers installed server side for our DPI code to work (should already be the case)
  • XP is probably not very relevant here, and every version of windows does things slightly differently - please read Writing DPI-Aware Desktop and Win32 Applications
  • you probably need a DPI above 120 to trigger automatic scaling on win32 - either set it manually, or using a hidpi display
  • opengl windows may or may not be affected by this scaling (and for that matter, maybe even non-opengl windows - in which case the change above does nothing at all)
  • we only have a single DPI value... so with multiple monitors, we end up with an average value
  • fontmatrix is a good little app that honours the Xft.dpi, many other apps (ie: Java apps) will read the "hardware" dpi instead (as per xdpyinfo)

Understanding the points above and their caveats:

  • verify that the DPI we detect is "correct" (the one that is set - more or less) - that's the value that gets printed as per comment:28 ':0.0' (1187x965 mm) workarea: 4720x2295 - DPI: 101x101
  • verify that we then set the correct DPI in the xpra session, using:
    • xrdb -query | grep dpi (note this value may actually be different from the "real" DPI with Linux clients because we sync the xrdb database for those, and so we mirror this setting.. unless the --dpi flag is used - confusing!)
    • xdpyinfo | grep -i dots
  • verify that if older xpra versions do get scaled by the OS (maybe only when turning off opengl?), newer ones don't
  • do we have problems with rotated displays? (detecting size and orientation, dpi, etc)

Last minute thoughts:

  • we could also add a runtime tray option to change the DPI.
  • do we want the dpi switch to also affect the dpi reported by xdpyinfo ("hardware" dpi) - I don't see why not.

comment:31 Changed 3 years ago by Antoine Martin

Well, now that I've beaten you to the testing, I've already found some issues, see #697.
Found some new DPI links:

comment:32 Changed 3 years ago by Antoine Martin

Priority: majorblocker

Raising priority because of the issues in #697, we need to identify the problems and also see if we have similar problems with OSX (and this one I still cannot test).

comment:33 Changed 3 years ago by Antoine Martin

FWIW: as long as I set SetProcessDPIAware early enough (see r7823 and #697 for details), I get 144 (which is correct?) on my 4k monitor by calling:

import ctypes, win32gui
gdi32=ctypes.windll.gdi32
dc = win32gui.GetDC(None)
print(gdi32.GetDeviceCaps(dc, LOGPIXELSX))
print(gdi32.GetDeviceCaps(dc, LOGPIXELSY))
win32gui.ReleaseDC(None, dc)

Which is the same value we get from GTK for the screen (not for the monitor!).

And here is something else which may be useful for testing / comparing: make older programs run in this version of windows: Disable display scaling on high DPI settings.

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:34 Changed 3 years ago by Antoine Martin

I couldn't wait for this to get tested, so I hope my assumptions were correct. r7843 makes us honour the client DPI values detecting using the platform specific code, both as Xft.dpi (for applications that honour this) and as "hardware" DPI.

If that works OK, we can then deal with OSX:

comment:35 Changed 3 years ago by alas

Testing with r7840 clients the results looked a lot like those I posted in #697 (though the Xft.dpi indicated a 96 dpi after I had manually set it to, arbitrarily, 181). Testing again with r7847 clients everything looks like it's being read as expected (though I still feel like the Display1 read shouldn't be using the DPI of 72 no matter what it's set to for hardware... probably just an OCD tic).

I'll post outputs with the 2560x1440 monitor, in case anything looks wrong (went back as far as the 0.14.0 client/server for comparison... in case).

  • 0.14.0 r7276 client (windows 7) - 0.14.0 r7255 server (fedora 20)

2560x1440 display
DPI 181:

2014-09-30 12:55:48,793 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 12:55:48,795   '2\WinSta-Default' (359x202 mm)
2014-09-30 12:55:48,796     DISPLAY1 (903x508 mm)
2014-09-30 12:55:48,970 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)

xrdp -query | grep dpi -> returns nothing (not even error message that led me to figure out correct syntax with later build)

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (looks good):

2014-09-30 13:05:18,378 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 13:05:18,381   '2\WinSta-Default' (202x359 mm)
2014-09-30 13:05:18,384     DISPLAY1 (508x903 mm)
2014-09-30 13:05:18,515 server: Linux Fedora 20 Heisenbug, Xpra version 0.14.0 (r7255)

  • 0.15.0 r7813 client (windows 7) - 0.15.0 r7794 server (fedora 20)

2560x1440 display
DPI 181:

2014-09-30 13:31:33,976 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 13:31:33,976   '2\WinSta-Default' (359x202 mm - DPI: 181x181)
2014-09-30 13:31:33,976     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 13:31:34,197 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)

xrdp -query | grep dpi -> returns nothing (again)

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (also looks good):

2014-09-30 13:37:35,865 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 13:37:35,865   '2\WinSta-Default' (202x359 mm - DPI: 181x181)
2014-09-30 13:37:35,867     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 13:37:36,009 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)

  • 0.15.0 r7840 client (windows 7) - 0.15.0 r7840 server (fedora 20)

2560x1440 display
DPI 181:

2014-09-30 13:49:26,119 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 13:49:26,121   '2\WinSta-Default' (359x202 mm - DPI: 181x181) workarea: 2560x1372
2014-09-30 13:49:26,124     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 13:49:26,342 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7840)

xrdb -query | grep dpi -> Xft.dpi: 96

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

rotated (also looks good):

2014-09-30 14:06:11,706 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 14:06:11,707   '2\WinSta-Default' (202x359 mm - DPI: 181x181) workare
a: 1440x2492
2014-09-30 14:06:11,711     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 14:06:11,923 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7840)

  • 0.15.0 r7847 client (windows 7) - 0.15.0 r7847 server (fedora 20)

2560x1440

DPI 181:

2014-09-30 15:04:19,463 desktop size is 2560x1440 with 1 screen(s):
2014-09-30 15:04:19,463   '2\WinSta-Default' (359x202 mm - DPI: 181x181) workare
a: 2560x1372
2014-09-30 15:04:19,464     DISPLAY1 (903x508 mm - DPI: 72x72)
2014-09-30 15:04:19,690 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

xrdb -query | grep dpi -> Xft.dpi: 181

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch

Still not scaled by OS (xterm frame is scaled up, but content within the frame isn't, making it look tiny).

Rotated (looks good):

2014-09-30 15:19:56,470 desktop size is 1440x2560 with 1 screen(s):
2014-09-30 15:19:56,470   '2\WinSta-Default' (202x359 mm - DPI: 181x181) workarea: 1440x2492
2014-09-30 15:19:56,473     DISPLAY1 (508x903 mm - DPI: 72x72)
2014-09-30 15:19:56,631 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

xpra info | grep client.screen

2014-09-30 16:12:12,361 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
client.screen[0].display=2\WinSta0\Default
client.screen[0].monitor[0].geometry=(0, 0, 2560, 1440)
client.screen[0].monitor[0].name=\\.\DISPLAY1
client.screen[0].monitor[0].size_mm=(903, 508)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(359, 202)
client.screen[0].workarea=(0, 0, 2560, 1372)
client.screens=1

Changed 3 years ago by alas

Attachment: ticket163-DPI_181-xterm.PNG added

Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content

comment:36 Changed 3 years ago by Antoine Martin

@afarr: this image is as expected I think.
Manually set high DPI on local displays rendered in xpra session xterm frames, but not xterm content

At least on Fedora. The exact font and dpi settings for xterm can be customized using:

  • the command line
  • /etc/X11/Xresources config file, and maybe also /etc/X11/Xresources/xterm
  • the per user version ~/.Xresources

So.. it is possible to get an xterm that uses a dpi aware font (bearing in mind that you must connect the client before running it):

xterm -fa "Lucida" -fs 10

To see what size a window is, you can use:

xpra info | grep -e "window.*\.size="

For the default "xterm", I always get 499 x 316, no matter what the dpi is set to.

Here are the sizes I get with the Lucida command line instead:

  • with DPI set to 101: 659 x 388
  • with DPI set to 144: 979 x 580

Note: r7852 makes it easier to disable SetProcessDPIAware using the environment variable XPRA_DPI_AWARE (use any value other than 1 to disable)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:37 Changed 3 years ago by alas

Testing with a windows 8.1 client using a 4K monitor:

  • 0.15.0 r7847 client vs. 0.15.0 r7847 fedora 20 server:

The DPI detected seems to be correct:

2014-10-01 11:50:15,138 desktop size is 3840x2160 with 1 screen(s):
2014-10-01 11:50:15,138   '1\WinSta-Default' (677x381 mm - DPI: 144x144) workarea: 

3840x2104
2014-10-01 11:50:15,138     DISPLAY1 (621x341 mm - DPI: 157x160)
2014-10-01 11:50:15,323 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

The DPI set in the session looks right:
xrdb -query | grep dpi -> Xft.dpi: 144

xdpyinfo | grep -i dots -> resolution: 45x60 dots per inch

While the xterms don't seem to scale, other applications (like google-chrome) do scale... and with the DPI detection of Windows 8.1 they actually scale dynamically as the settings are changed.

2014-10-01 15:58:53,983 unexpected message: WM_MOVE / 0 / 7340110
2014-10-01 15:58:54,964 sending updated screen size to server: 2880x1620 with 1
screens
2014-10-01 15:58:54,966   '1\WinSta-Default' (508x285 mm - DPI: 144x144) workare
a: 2880x1578
2014-10-01 15:58:54,967     DISPLAY1 (621x341 mm - DPI: 117x120)
2014-10-01 15:59:08,905 unexpected message: WM_MOVE / 0 / 8978535

Rotated displays don't seem to be problematic (switching to portrait and re-connecting produced this client output):

2014-10-01 12:49:53,051 desktop size is 2160x3840 with 1 screen(s):
2014-10-01 12:49:53,052   '1\WinSta-Default' (381x677 mm - DPI: 144x144) workarea: 2160x3784
2014-10-01 12:49:53,052     DISPLAY1 (341x621 mm - DPI: 160x157)
2014-10-01 12:49:53,273 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7847)

... and seems to work even on the fly:

2014-10-01 16:03:42,769 unexpected message: WM_MOVE / 0 / 14090300
2014-10-01 16:03:43,746 sending updated screen size to server: 2160x3840 with 1
screens
2014-10-01 16:03:43,746   '1\WinSta-Default' (381x677 mm - DPI: 144x144) workare
a: 2160x3784
2014-10-01 16:03:43,747     DISPLAY1 (341x621 mm - DPI: 160x157)
  • Connecting with or without opengl doesn't seem to make any difference, either with the new clients or the old, as far as DPI detection is concerned.
  • Older clients were definitely reading higher DPI incorrectly (Xpra menu placement was asurprise even after a warning) ...
0.15.0 r7813 client (windows 8.1) - 0.15.0 r7794 server (fedora 20) 


2014-10-01 15:22:48,138 desktop size is 2560x1440 with 1 screen(s):
2014-10-01 15:22:48,138   '1\WinSta-Default' (451x254 mm - DPI: 144x144)
2014-10-01 15:22:48,138     DISPLAY1 (621x341 mm - DPI: 104x107)
2014-10-01 15:22:48,319 server: Linux Fedora 20 Heisenbug, Xpra version 0.15.0 (r7794)

client.screen[0].display=1\WinSta0\Default
client.screen[0].monitor[0].geometry=(0, 0, 2560, 1440)
client.screen[0].monitor[0].name=\\.\DISPLAY1
client.screen[0].monitor[0].size_mm=(621, 341)
client.screen[0].size=(2560, 1440)
client.screen[0].size_mm=(451, 254)
client.screen[0].workarea=(0, 0, 2560, 1440)
client.screens=1

xrdb -query | grep dpi -> Xft.dpi: 96

xdpyinfo | grep -i dots -> resolution: 30x34 dots per inch
  • Note, I did manage to break a google-chrome browser with the newer revision:

... Go to site with video, maximize video, use Esc key to un-maximize video.

Results in the loss of the browser's "outside frame", and with it the ability to un-maximize/resize page. (Might be result of pepper-flash plugin?)

Client-side CLI output:

Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:00,595 with hints={}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:03,362 re-starting speaker because of overrun
2014-10-01 13:00:04,260 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2014-10-01 13:00:08,288 with hints={'min_width': 357, 'min_height': 82}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)
2014-10-01 13:00:08,289 with hints={'min_width': 357, 'min_height': 82}
Traceback (most recent call last):
  File "xpra\client\client_window_base.pyc", line 237, in set_size_constraints
TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)

... Meanwhile, testing with firefox, it looks like the fullscreen video is being rendered as oddly as the session info was being rendered previously (will include a screenshot, no sign of logging in client or server output).

Changed 3 years ago by alas

firefox fullscreen on 4K monitor displays mostly "offscreen"

comment:38 Changed 3 years ago by alas

  • One additional note, testing again with 2560x1440 monitor (default 96 DPI), the fullscreen firefox video played as expected (same server session).

comment:39 Changed 3 years ago by Antoine Martin

Testing with a windows 8.1 client using a 4K monitor:
(...)
xrdb -query | grep dpi -> Xft.dpi: 144


OK, good.

xdpyinfo | grep -i dots -> resolution: 45x60 dots per inch


Ouch. That looks wrong. The DPI shown by xdpyinfo should also be the correct DPI.
Are you sure that your Fedora server has the patched Xdummy driver? Check with rpm -qa | grep dummy

While the xterms don't seem to scale..


xterms should scale as per comment:36, does it not?

... other applications (like google-chrome) do scale... and with the DPI detection of Windows 8.1 they actually scale dynamically as the settings are changed.
2014-10-01 15:58:54,964 sending updated screen size to server: 2880x1620 with 1 screens


I don't understand what you did here. Did you change the resolution at that point? Or change the DPI? or what?
We should always be detecting the correct, current, unscaled resolution. And this is not a 4k resolution.
And more importantly: which is the "correct" DPI in the data shown? (and by correct, I mean: the one we should be using for rendering - whatever that may be..)

Rotated displays don't seem to be problematic (switching to portrait and re-connecting produced this client output):
(...)
... and seems to work even on the fly:


OK, very good.

Connecting with or without opengl doesn't seem to make any difference, either with the new clients or the old, as far as DPI detection is concerned.


OK, this is expected - rendering happens much later, still good to confirm.

Older clients were definitely reading higher DPI incorrectly (Xpra menu placement was asurprise even after a warning) ...
(...)
desktop size is 2560x1440 with 1 screen(s):


This is the same as my query above. This is a scaled resolution and is part of the bug this ticket is meant to fix.
Hence why I am wondering how you got 2560x1440 with the new code.

TypeError: apply_geometry_hints() takes exactly 2 arguments (1 given)


Moved to: ticket:263#comment:14 - should be fixed.
Not sure if this was the cause of the missing "outside frame". Please confirm, and file another ticket for that if this is still a problem. (and link back to this one)

... Meanwhile, testing with firefox, it looks like the fullscreen video is being rendered as oddly as the session info was being rendered previously (will include a screenshot, no sign of logging in client or server output).


Oh, is this a regression caused by these changes?
If not, this should go in a different ticket. (and link back to this one)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:40 Changed 3 years ago by alas

Are you sure that your Fedora server has the patched Xdummy driver?

As a matter of fact, I had an old xdummy driver... updated and ran xdpyinfo | grep -i dots... resolution: 144x144 dots per inch. Much better I'm sure.

xterms should scale as per comment:36, does it not?

I was actually just mentioning the xterms to contrast with the scaling behavior of the browsers (which were re-scaling dynamically as I adjusted the display's "Change the size of all items" slider, which appears to be the windows 8.1 version of the DPI manual adjustment option)... but re-examining more closely, it looks like adjusting the size slider with windows 8.1 does adjust the text/content size, as well as window frame size, of the displayed xterms, but xpra info | grep -e "window.*\.size=" nevertheless consistently outputs window[].size=(499, 316). Without the option of setting absurd custom DPI settings though, I'm not sure if scaling DPI upward would adjust the content size as well, or if it is only because the only options I'm seeing are adjusting the content toward a smaller size (which would be toward a higher DPI, if I haven't completely confused myself at this point).

I don't understand what you did here. Did you change the resolution at that point? Or change the DPI? or what?

As I mentioned above, I was adjusting the display's "item size slider" (for lack of a better name), and the output was reflecting the client-side output as the server detected the changes in the "display size" As a general rule I'm finding that the 3rd of 4 sizes is most comfortable on the eyes, which means that most of the shifting has been toward smaller display sizes.

  • Note, on the windows 8.1 slider there are only 4 settings, and apparently no support for custom settings (or at least not that I've found so far).
  • Testing more carefully with a 4K monitor, adjusting statically before connection, I get the following:
  • The "largest" setting gives this output:
    2014-10-02 11:39:06,503 sending updated screen size to server: 2880x1620 with 1
    screens
    2014-10-02 11:39:06,503   '1\WinSta-Default' (508x285 mm - DPI: 144x144) workarea: 2880x1578
    2014-10-02 11:39:06,505     DISPLAY1 (621x341 mm - DPI: 117x120)
    

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

  • 2nd largest:
    2014-10-02 11:56:45,641 desktop size is 3840x2160 with 1 screen(s):
    2014-10-02 11:56:45,641   '1\WinSta-Default' (677x381 mm - DPI: 144x144) workarea: 3840x2104
    2014-10-02 11:56:45,641     DISPLAY1 (621x341 mm - DPI: 157x160)
    

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

  • 3rd largest:
    2014-10-02 11:44:16,207 sending updated screen size to server: 4608x2592 with 1
    screens
    2014-10-02 11:44:16,209   '1\WinSta-Default' (812x457 mm - DPI: 144x144) workarea: 4608x2525
    2014-10-02 11:44:16,209     DISPLAY1 (621x341 mm - DPI: 188x193)
    

xdpyinfo | grep -i dots => resolution: 144x144 dots per inch

  • 4th largest (aka smallest):
    2014-10-02 11:48:52,930 sending updated screen size to server: 5760x3240 with 1
    screens
    2014-10-02 11:48:52,931   '1\WinSta-Default' (1016x571 mm - DPI: 144x144) workarea: 5760x3183
    2014-10-02 11:48:52,931     DISPLAY1 (621x341 mm - DPI: 235x241)
    

xdpyinfo | grep -i dots => resolution: 230x184 dots per inch

  • Oddly, adjusting dynamically gives the same output for changes, except when changing back to the original "size slider" setting, upon which adjustment the client doesn't output any new information (though the displayed size adjusts as expected).

Hence why I am wondering how you got 2560x1440 with the new code.

I didn't get that with the new code, I got it with the old. (You asked that we "verify that if older xpra versions do get scaled by the OS (maybe only when turning off opengl?), newer ones don't" ... this verified that the older version did scale down to the 2560x1440, while the new now recognizes the 4 apparent options that windows 8.1 offers for a 4K display.)

  • As for the firefox issue, since it doesn't happen on a 2560x1440 monitor at fullscreen with the same client (but windows 7 vs. 8.1) and not only the same server but when connecting to the same server session, I assume it is a regression. (Just to be thorough, I switched the 8.1 machine to the 2560x1440 display, and the fullscreen video played as expected... so it is either a regression with the new changes as they affect play on 4K monitors, or the lack of significant testing on firefox with 4K monitors previously just resulted in us never finding it before...)

comment:41 Changed 3 years ago by Antoine Martin

adjusting the size slider with windows 8.1 does adjust the text/content size
(...)
nevertheless consistently outputs window[].size=(499, 316)


This means that windows 8.1 is upscaling the window for us.
Which is very odd, because when we set SetProcessDpiAware, I thought it would just stop doing that, and stop lying to us!

"Change the size of all items"


Could well be the problem. Looks like I need to also install windows 8.1 somewhere to test. Oh joy.

And maybe use ​SetProcessDpiAwareness as well as ​SetProcessDpiAware..

4608x2592
5760x3240


!!
That's way bigger than 4k!
My guess is that windows is lying to the applications and downscaling when putting stuff on screen.


Hence why I am wondering how you got 2560x1440 with the new code.

I didn't get that with the new code, I got it with the old.

What about the data found in this comment? (comment:40)
Is this with the new or old code? (me, totally confused now)


As for the firefox issue..


Please create a separate ticket for this one, and link back to this ticket.
We need the usual: xpra info, compare with windows 7, windows 8, etc..

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:42 Changed 3 years ago by alas

What about the data found in this comment? (comment:40)

Now I'm confused. In comment:40 the reference I made to the 2560x1440 monitor referred to me physically attaching a 2560x1440 display to the windows 8.1 machine to repeat the fullscreen test with firefox to see if it was just behavior related to the 4K display, or if it was somehow related to the windows 8.1 OS itself.

The mention of "2880x1620 with 1 screens" in one of the sets of output was what the client output interpreted the screen size as when I set the "size slider" to its "largest" setting.

The reference to "desktop size is 2560x1440 with 1 screen(s)" in comment:37 was the client-side output with the old (0.15.0 r7813 client) client code.

Was there another reference that I'm missing?

comment:43 Changed 3 years ago by alas

Well, that is odd.

Trying to reproduce the firefox issue with 0.15.0 r7897 win32 client (windows 8.1 w/4K monitor) vs. 0.15.0 r7897 server (fedora 20)... it seems to be completely solved and unreproduceable.

Nice work...

comment:44 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

I think we can close this for now.

comment:45 Changed 3 years ago by alas

  • Some odd window client side size related output to keep in mind:
2014-11-24 17:23:16,164   '1\WinSta-Default' (1016x571 mm)
2014-11-24 17:23:16,165     DISPLAY1 (621x341 mm)
2014-11-24 17:24:16,562 unexpected message: WM_MOVE / 0 / 1703999
2014-11-24 17:24:17,548 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:24:17,549   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:24:17,549     DISPLAY1 (621x341 mm)
2014-11-24 17:26:11,614 unexpected message: WM_MOVE / 0 / 1703990
2014-11-24 17:26:11,615 unexpected message: WM_SIZE / 0 / 46203774
2014-11-24 17:26:12,578 sending updated screen size to server: 1280x720 with 1 s
creens
2014-11-24 17:26:12,579   '1\WinSta-Default' (338x190 mm)
2014-11-24 17:26:12,579     DISPLAY1 (621x341 mm)
2014-11-24 17:26:28,826 unexpected message: WM_MOVE / 0 / 1704001
2014-11-24 17:26:29,799 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:26:29,801   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:26:29,802     DISPLAY1 (621x341 mm)
2014-11-24 17:27:08,217 unexpected message: WM_MOVE / 0 / 1703991
2014-11-24 17:27:09,184 sending updated screen size to server: 1280x720 with 1 s
creens
2014-11-24 17:27:09,184   '1\WinSta-Default' (338x190 mm)
2014-11-24 17:27:09,184     DISPLAY1 (621x341 mm)
2014-11-24 17:27:28,611 unexpected message: WM_MOVE / 0 / 1704017
2014-11-24 17:27:29,604 sending updated screen size to server: 1920x1080 with 1
screens
2014-11-24 17:27:29,605   '1\WinSta-Default' (508x285 mm)
2014-11-24 17:27:29,605     DISPLAY1 (621x341 mm)
2014-11-24 17:29:00,207 unexpected message: WM_MOVE / 0 / 1704043
2014-11-24 17:29:09,625 unexpected message: WM_MOVE / 0 / 1704064
2014-11-24 17:29:10,612 sending updated screen size to server: 3072x1728 with 1
screens
2014-11-24 17:29:10,614   '1\WinSta-Default' (812x457 mm)
2014-11-24 17:29:10,615     DISPLAY1 (621x341 mm)
2014-11-24 17:35:36,171 unexpected message: WM_MOVE / 0 / 1704001
2014-11-24 17:35:36,740 unexpected message: 800 / -952262963 / 1
2014-11-24 17:35:36,799 unexpected message: 800 / -952262194 / 1
2014-11-24 17:35:36,857 unexpected message: 800 / -952261683 / 1
2014-11-24 17:35:36,927 unexpected message: 800 / -952260915 / 1
2014-11-24 17:35:36,983 unexpected message: 800 / -952260147 / 1
2014-11-24 17:35:37,052 unexpected message: 800 / -952259635 / 1
2014-11-24 17:35:37,115 unexpected message: 800 / -952258867 / 1
2014-11-24 17:35:37,142 sending updated screen size to server: 1536x864 with 1 s
creens
2014-11-24 17:35:37,142   '1\WinSta-Default' (406x228 mm)
2014-11-24 17:35:37,142     DISPLAY1 (621x341 mm)
2014-11-24 17:35:37,176 unexpected message: 800 / -952258099 / 1
2014-11-24 17:35:37,243 unexpected message: 800 / -952257331 / 1
2014-11-24 17:35:37,305 unexpected message: 800 / -952256564 / 1
2014-11-24 17:35:37,365 unexpected message: 800 / -952256051 / 1
2014-11-24 17:35:37,434 unexpected message: 800 / -952255283 / 1
2014-11-24 17:35:37,490 unexpected message: 800 / -952254516 / 1
2014-11-24 17:35:37,561 unexpected message: 800 / -952254004 / 1
2014-11-24 17:35:37,622 unexpected message: 800 / -952253236 / 1
2014-11-24 17:35:37,650 unexpected message: 800 / -952252724 / 1

Obtained by manipulating the two different DPI input methods available with Windows 8.1 (Control Panel\Appearance and Personalization\Display vs. Control Panel\Appearance and Personalization\Display\Screen Resolution).

The Screen Resolution page allows direct manipulation of the actual display size, while the Display page allows the use of a slider between "Smaller" (which renders the display at the size indicated in the "Screen Resolution" settings) up through a number of options until reaching "Larger" (which increases the size of text by reducing the screen size(?) and thereby increasing the DPI(?)).

When all is said and done (and interpreted), the '1\WinSta-Default' value is usually rather fictional, while the DISPLAY1 size is accurate.

Confusion is now documented better... with any luck it will help in the future.

comment:46 Changed 2 years ago by Antoine Martin

More DPI values recorded in ticket:885#comment:9

comment:47 Changed 2 years ago by Antoine Martin

See also: ticket:976#comment:15 and r10832.

comment:48 Changed 2 years ago by Antoine Martin

Very relevant post: Of DPIs, desktops, and toolkits:


GTK+ is written to use the values from xsettings or the X resource database, if there are any. But what does it do when nothing has written the settings?

(..)
As of Monday, it would default to hintstyle ‘full’, and for the DPI, it would calculate it from the resolution and the display size reported by X. I found that, on the test VM, with a resolution of 1024×768, xdpyinfo reported the display size as 270x203mm. The calculation uses the vertical values, so we get: 768 / (203 / 25.4) * 1024 = 98400.851231527 , which rounds up to 98401 – the gtk-xft-dpi value we found that boot.iso was using! Eureka.
and:
ou can press ctrl+shift+d (or ctrl+shift+i) in any running GTK+ 3 app to launch GtkInspector?, a rather handy debugging tool. By clicking the GtkSettings? ‘object’ and then going to ‘Properties’, we can see the relevant settings (down at the bottom): gtk-xft-antialias, gtk-xft-dpi, gtk-xft-hinting and gtk-xft-hintstyle.


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

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:49 Changed 2 years ago by 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 wiki/DPI, see also #1086.

Last edited 2 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.