Community
Participate
Working Groups
Since the fix for Bug 535064 there is an issue with Device#getDPI method that can under some unclear conditions return an incorrect DPI. Since my comment in the original bug went unnoticed I'm creating a new bug to raise this issue. Here's my comment in the original bug: I'm noticing a strange behavior of Device#getScreenDPI on my system (Ubuntu 18.04 with latest updates, and GTK version 3.22.30). The returned DPI value is {102, 102} instead of {96,96} as it should be. I've tried to debug the issue and here are the values used for DPI calculation: widthMM=480,scaleFactor=1,monitorGeometry={0, 0, 1920, 1080} This gives 254*1920/(480*10.0) = 101.6, value then rounded to 102. I've tried to reproduce this issue with VirtualBox with a clean 18.04 install but couldn't. Although it's the same system, returned widthMM is different: widthMM=503,scaleFactor=1,monitorGeometry={0, 0, 1920, 988} Which gives 254*1920/(503*10.0) = 96.0, which is correct. Is this a bug? Running $ xrandr --query gives Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 480mm x 270mm So the 480mm value is there, but I am not sure what this means. The result is that Eclipse 4.9 and onward return and incorrect DPI value on my system. "xrdb -query | grep dpi" gives the correct DPI as follows: Xft.dpi: 96
And I have a client with an even more extreme case. The output of "xrandr --query" on their machine gives: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm And "xrdb -query | grep dpi": Xft.dpi: 96 This means that the system has the dpi of 96, but the algorithm used by SWT calculates the DPI as round(254*1920/(344*10.0)) = 142, which is way off. A need an urgent solution for this issue.
Thanks for raising this issue, we'll investigate for 4.12.
Unfortunately we have run out of time for 4.12, will investigate for 2019-09.
*Sigh* sorry, I didn't manage to get to this one in time. It's on the list for first thing in 4.14.
So it seems like algorithm for the screen DPI is inaccurate, which I can tweak. May I ask what you are using the returned DPI value for?
Eric, in WireframeSketcher text sizes are specified in pixels, to ensure that the size doesn't change between devices with different DPIs. When creating SWT Font objects I need to calculate the size in points (FontData#setHeight). So I am using the DPI value of the screen to transform pixel sizes to points.
(In reply to Peter Severin from comment #6) > Eric, in WireframeSketcher text sizes are specified in pixels, to ensure > that the size doesn't change between devices with different DPIs. When > creating SWT Font objects I need to calculate the size in points > (FontData#setHeight). So I am using the DPI value of the screen to transform > pixel sizes to points. Okay, I just wanted to check. I spoke to the upstream GTK devs about this subject and they pointed out many different ways to get DPI. It seems the SWT use case is the DPI for text/image scaling, which can sometimes be different than "generic screen DPI". I'll propose a patch for 4.14.
New Gerrit change created: https://git.eclipse.org/r/149192
Gerrit change https://git.eclipse.org/r/149192 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=f1cec2dde6ea77ca066ebe3a405f7ced98098903
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/149192 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=f1cec2dde6ea77ca066ebe3a405f7ced98098903 In master now.
New Gerrit change created: https://git.eclipse.org/r/149369
Gerrit change https://git.eclipse.org/r/149369 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3c0e74f1ed5a447b60eb0a783979cf9144e65960
*** Bug 542649 has been marked as a duplicate of this bug. ***
Verified in I20191008-0600.
