Community
Participate
Working Groups
The issue was introduced in Bug 518717. See Comment 7 and following comments: https://bugs.eclipse.org/bugs/show_bug.cgi?id=518717#c7 Snippet to test the issue: Display display = new Display(); System.out.println(display.getDPI()); The returned dpi is 192. Under the same conditions getDPI method returns 96 on Windows, and 74 on macOS. So the correct value should be 96. This issue was introduced in 4.8 and only affects this version. I believe it's an important breakage of the API and should be fixed before the final release, or it least in the first point release. Not in 4.9.
@Leo, I am having trouble in adding optional GTK calls to GTK.java. I will create a patch tomorrow. Can you have a look?
(In reply to Sravan Kumar Lakkimsetti from comment #1) > @Leo, > > I am having trouble in adding optional GTK calls to GTK.java. I will create > a patch tomorrow. Can you have a look? What do you mean by optional? like dyanmic?
New Gerrit change created: https://git.eclipse.org/r/124539
(In reply to Leo Ufimtsev from comment #2) > (In reply to Sravan Kumar Lakkimsetti from comment #1) > > @Leo, > > > > I am having trouble in adding optional GTK calls to GTK.java. I will create > > a patch tomorrow. Can you have a look? > > What do you mean by optional? > > like dyanmic? > New Gerrit change created: https://git.eclipse.org/r/124539 Can you have a look at the attached patch I am unable to build natives with this.(In reply to Eclipse Genie from comment #3)
New Gerrit change created: https://git.eclipse.org/r/124573
Gerrit change https://git.eclipse.org/r/124573 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=dca6f677b85c2d83c4b6378dfcc811694796cc53
(In reply to Eclipse Genie from comment #6) > Gerrit change https://git.eclipse.org/r/124573 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=dca6f677b85c2d83c4b6378dfcc811694796cc53 Merged to master
Sravan, can you please take a look at the fails in Platform UI Ferrit, see bug 535992? Could they be related to the changes on this bug?
(In reply to Andrey Loskutov from comment #8) > Sravan, can you please take a look at the fails in Platform UI Ferrit, see > bug 535992? Could they be related to the changes on this bug? I've commented on the patch. The NaN in FontData could be from float size = height * screenDPI.y / dpi.y; and this would mean we compute "0" for the screen dpi in org.eclipse.swt.graphics.Device.getScreenDPI().dpi.
(In reply to Andrey Loskutov from comment #9) > (In reply to Andrey Loskutov from comment #8) > > Sravan, can you please take a look at the fails in Platform UI Ferrit, see > > bug 535992? Could they be related to the changes on this bug? > > I've commented on the patch. The NaN in FontData could be from > > float size = height * screenDPI.y / dpi.y; > > and this would mean we compute "0" for the screen dpi in > org.eclipse.swt.graphics.Device.getScreenDPI().dpi. There is a case where we have this. I have a solution. I am testing it right now. If it is succesful I will push and trigger a I-build
New Gerrit change created: https://git.eclipse.org/r/124666
Gerrit change https://git.eclipse.org/r/124666 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=33dc42ff9cc2b110d9bcebe339cc358dff028ff4
fixed with https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=33dc42ff9cc2b110d9bcebe339cc358dff028ff4
verified in 4.9M2
Hi Sravan, 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.
(In reply to Peter Severin from comment #15) > Hi Sravan, > > 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. We rely on GTK api to get the physical dimensions from the hardware. It would vary from screen to screen based on the physical dimensions. This is expected. During our hidpi implementation we quickly realized dpi calculation is not reliable. Many times the display driver doesn't have dimensions in mm in its properties then a dpi of 96 is assumed. So we rely on the scaling factor directly.
My issue is not directly related to HiDPI and I have it in non-scaled environment too. It's just that the issue was introduced during the change in this bug. I've created a separate Bug 545953 for the issue I'm seeing. In my use case I need the screen DPI to convert font sizes from pixels (as they are specified in WireframeSketcher) to points to get the correct text size on screen. Since font heights are specified in points I don't see how I can calculate font height without knowing the DPI. The getDPI() method generally worked reliably before 4.9, and the issue with incorrect values only appears on GTK. All other plaforms return the DPI correctly. Are you saying that there is no fix for getDPI on GTK and I should use other means to discover screen DPI in my application?
dpi by definition dots per inch. In GTK we get number of pixels width wise and length in mm. From this we calculate the dpi. If we look at newer monitors with full HD resolution 14 inch corresponds to 157 15 inch to 148 With getDPI() method we are calculating this value and returning it. DPI will always depend on dimensions of the monitor. For historical reasons windows and MAC decided to base their OS design on 96 and 72 pixels respectively. To convert this actual physical scale you'll need actual DPI. During the hidpi implementation we decided to go ahead with scaling factor as the DPI is very much unreliable and user controls the scaling factor using display settings. On windows and MAC we get the dpi value using a OS call and return that value. But GTK doesnot have a call to directly get dpi. So we calculate it using the physical dimensions. Only way forward I see (though not correct in my opinion) is to hardcode 72 and 96 for mac and windows/linux for display
