Community
Participate
Working Groups
The function gdk_screen_width_mm() is deprecated as of GTK3.22.
Deprecation of gdk_screen_width_mm() is causing failure in Display.getDPI() API. Need to fix this API in linux. Device.getDeviceZoom() has different implementation to get dpi. See bug 530932 comment 34 for details.
I am seeing this issue on GTK 3.18.9 too, and only with Eclipse 4.8. On Eclipse 4.7 the DPI is retrieved correctly, although the same method is being used there too.
New Gerrit change created: https://git.eclipse.org/r/122657
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/122657 +1 for RC1
Gerrit change https://git.eclipse.org/r/122657 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=918497a03146e470781caa9f737d37186e0bda00
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/122657 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=918497a03146e470781caa9f737d37186e0bda00 Merged to master
I'm testing the latest I20180515-2000 build on HiDPI display with x2 scaling. The new implementation works differently, but I believe it's still wrong. I am testing with the following snippet: Display display = new Display(); System.out.println(display.getDPI()); The returned dpi is 192. I believe the correct value should be 96. I also see some regressions in Bug 494724 and Bug 525957 when running on GTK2. Perhaps it might be related to this fix too.
(In reply to Peter Severin from comment #7) > I'm testing the latest I20180515-2000 build on HiDPI display with x2 > scaling. The new implementation works differently, but I believe it's still > wrong. I am testing with the following snippet: > > Display display = new Display(); > System.out.println(display.getDPI()); > > The returned dpi is 192. I believe the correct value should be 96. I also > see some regressions in Bug 494724 and Bug 525957 when running on GTK2. > Perhaps it might be related to this fix too. That is expected behavior 100% scaling corresponds to 96 DPI on Windows and Linux in case of Mac is is 72. At 200% the scale will increase by a factor of 2.
Why do you run on GTK2 ? We are seriously discussing to drop GTK2 support so you would better raise your issue to our knowledge.
Under the same conditions, with x2 scaling, getDPI method returns 96 on Windows and not 192. On Mac DPI also stays the same between x1 and x2 scaling. So this is inconsistent with current behavior. My understanding is that since SWT applications are scaled transparently they shouldn't see the doubled DPI.
I distribute WireframeSketcher as an RCP application and un until now (even with Eclipse 4.7) GTK2 worked in a consistent manner, unlike GTK3 support which is plagued by various issues. GTK3 is finally starting to look good in Eclipse 4.8. But as long as GTK2 is support is there I believe it should work correctly so it can be used as a fallback.
No one is looking after gtk2 specific bugs so if stops working - so be it. This is just a heads up :).
(In reply to Peter Severin from comment #11) > I distribute WireframeSketcher as an RCP application and un until now (even > with Eclipse 4.7) GTK2 worked in a consistent manner, unlike GTK3 support > which is plagued by various issues. GTK3 is finally starting to look good in > Eclipse 4.8. But as long as GTK2 is support is there I believe it should > work correctly so it can be used as a fallback. Please file bugs for all the GTK3 issues you experience -- we are making these a priority for the next several releases.
Eric, I did. They were mostly HiDPI issues which are now being fixed in 4.8. This bug here is still not fixed in my opinion as I've shown above, but I hope that Sravan we'll look into it and adjust the fix.
(In reply to Peter Severin from comment #14) > Eric, I did. They were mostly HiDPI issues which are now being fixed in 4.8. > This bug here is still not fixed in my opinion as I've shown above, but I > hope that Sravan we'll look into it and adjust the fix. Okay thanks. :) If you encounter any other issues, feel free to file bugs for them and add me as CC.
I am not sure exactly what value getDPI should return. My take here is it should return based on the scaling factor. Otherwise this API is useless as it always returns 96 regardless of the monitor or scale etc.
Can you please provide a usecase where it is used so that I can understand how this can be sorted
There are few places that I know of where this method is used: * WireframeSketcher is using it to perform font size calculations that are expressed in pixels and not in points. The fact the the pixel size is doubled on x2 display should not affect this calculations. * GEF draws rulers for Inch and Centimeter units. I've never used those, so not sure if these are affected. By since rulers are drawn using GC which automatically scaled, I can deduce that this code is also broken as thing would be scaled twice, once via getDPI value and once via scaled graphics. * CTabFolderRenderer uses this method to draw chevron when too many tabs are created. This is also broken and perhaps there should be another bug for that. I'm attaching a screenshot for that.
Created attachment 274070 [details] Broken chevron rendering
To conclude, the way I understand it, Device#getDPI represents a logical DPI value and not a physical one and should be in sync with how GC works. Since GC transparently doubles pixels, the getDPI should be transparently adjusted to reflect that. So in this case, if GTK3 does this adjustment already - then just return that value, otherwise adjust it (it's probably a division by scale and not a multiplication). I also filed Bug 534768 with another issue with HiDPI on GTK3.
Is there any chance for this to get fixed for 4.8? Or should I create a different bug?
(In reply to Peter Severin from comment #21) > Is there any chance for this to get fixed for 4.8? Or should I create a > different bug? Please raise another bug. I will fix it in early 4.9
I filed Bug 535064 and Bug 535065
verified in Eclipse SDK Version: Photon (4.8) Build id: I20180524-0900 OS: Linux, v.4.16.10-300.fc28.x86_64, x86_64 / gtk 3.22.30 Java version: 1.8.0_171
