Community
Participate
Working Groups
In Bug 533135 dpi awareness is added for win32. However, the dpi awareness is not consistently configured. This functionality is added by configuring a (external) java.exe.manifest. The dpi awareness settings changed with the different Java versions. Java 8, uses dpi aware system [1], Java 9 uses dpi aware per monitor [2], Java 11 uses dpi aware per monitor v2 (with fallback to per monitor and system) [3]. Also the Eclipse launcher uses its own settings, namely dpi aware system [4]. Moreover, dpi awareness is not only configured in the manifest, but it can also be configured via API [5]. Modern Windows 10 system even support mixed mode DPI scaling [6]. Also SWT uses this API to configure DPI aware system for Vista and higher, see OS.java static initialize block. The result of this is that SWT behaves differently when launched with different Java versions. For the Eclipse case, it is even dependent on how the JVM is selected (as library or executable with the -vm option), see also Bug 571209. To get dpi awareness consistently enabled: - Validate if the manifest workaround of Bug 533135 is still needed, and update documentation accordingly. - eclipse.exe.manifest should be updated to the proper dpi awareness settings. - OS.java should be made robust for different manifest configurations, i.e. use the correct API calls. Be aware that these changes can make Bug 571209 more prominent. [1] https://bugs.openjdk.java.net/browse/JDK-8073320 [2] https://github.com/AdoptOpenJDK/openjdk-jdk9u/blob/master/jdk/src/java.base/windows/native/launcher/java.manifest [3] https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/windows/native/launcher/java.manifest [4] https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/features/org.eclipse.equinox.executable.feature/library/win32/eclipse.exe.manifest [5] https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows [6] https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications
@Niraj would you be able to help out here?
Just a back-ground on the current 'dpiAware' and 'dpiAwareness' settings in javaw.exe.manifest: On Windows10 when we change the Display Scale factor to say 175% from the default 150%, SWT receives SWT.ZoomChanged event from the native. On SWT.ZoomChanged event Eclipse notifies user to re-start Eclipse to proper scale at increased zoom value. Receiving SWT.ZoomChanged event was possible only with mentioned 'dpiAware' and 'dpiAwareness' settings. ----------------------------------------------------------------------------- To experiment with, we can still configure an external 'javaw.exe.manifest' on Windows, sharing the exact steps below: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533135#c5 As per comment 0, since Java 8 to Java 9 to Java 11 these dpi setting are updated. And SWT seems to be using Let us know if you find a better javaw.exe.manifest configuration, I will also check my side on this. Thanks!
I think that the main issues is with the eclipse.exe.manifest file used to create the eclipse launcher in equinox framework. This manifest is not up to date with the recommended java.exe.manifest as provided by SWT. Best would be that SWT is not depending on any manifest configuration, but using API calls, such that it would work in any environment. On modern windows, this could even be a per thread setting.
(In reply to Rolf Theunissen from comment #3) > I think that the main issues is with the eclipse.exe.manifest file used to > create the eclipse launcher in equinox framework. This manifest is not up to > date with the recommended java.exe.manifest as provided by SWT. Ok, I am planning to update eclipse.exe.manifest on same lines as SWT's java.exe.manifest to avoid differences in the dpi settings here. I hope this should help avoid the inconsistency part that you noticed. Let's explore/test this out first, if this doesn't work we can explore other options like below. > Best would be that SWT is not depending on any manifest configuration, but > using API calls, such that it would work in any environment. On modern > windows, this could even be a per thread setting.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/187779
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/187779 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=0bdb84facce5e1da8ba39f6ccf58e953372d45c8
Hi Rolf/Ed, Please try out the latest Eclipse IBuild: https://download.eclipse.org/eclipse/downloads/drops4/I20211116-0600/ Let us know if things have improved.
(In reply to Niraj Modi from comment #7) > Hi Rolf/Ed, > Please try out the latest Eclipse IBuild: > https://download.eclipse.org/eclipse/downloads/drops4/I20211116-0600/ > > Let us know if things have improved. With this change, for me, both with the eclipse.exe as well as the runtime instance (java.exe), Eclipse follows the DPI of the screen with each of the windows. However, launching with eclipsec.exe does not enable the per window scaling and results in a blurry screen when moving to another screen resolution. Is there a separate manifest for the eclipsec.exe executable? Niraj, if you or somebody else can also take a look at Bug 571209, this will get more prominent and results in a deadlock in the IDE.
Oh my god, no!!! It's horrible. This is exactly the problem I had and needed to fix by disabling this behavior for javaw.exe. Now I will have to fix ever single installation's *.exe manually. This is such a no go. :-(
Created attachment 287531 [details] Big menu/title fonts but unreadable everything else
I cannot emphasis enough that for me this makes Eclipse unusable in my multi-monitor environment. I have 3 monitors with 100%, 150%, and 225% scaling. Every window that I move from monitor to monitor scales such that the fonts are roughly the same physical size. But now Eclipse is the only application that is completely ill behaved. If Eclipse is going to claim to be aware of DPI to the OS it will need to scale fonts and images properly, but it does not do that. It should let the operating system do the scaling. Please please revert this change. Don't release like this. I can only make Eclipse usable by manually telling the OS not to let the application do the scaling.
(In reply to Ed Merks from comment #9) > Oh my god, no!!! It's horrible. This is exactly the problem I had and > needed to fix by disabling this behavior for javaw.exe. Now I will have to > fix ever single installation's *.exe manually. This is such a no go. :-( Alright, I missed to noticed that scaling doesn't happen for all widgets. With the old settings, the majority of the text seems to scale, but can get blurry. With the new settings, many widgets fail to react to the resize event (and even Eclipse might need a restart to properly deal with it). So as opposed to what is suggested by other bug fixes (e.g Bug 533135 and https://www.eclipse.org/swt/faq.php#win10dpiawareness), SWT 4.8 did not bring per-monitor HiDPI scaling for the windows system. If SWT does not do per-monitor scaling, it should also not be enabled in the manifest. But then it should be prevented that it is enabled when loaded with a modern java JRE. (So back to the robust API suggestion that will work independent from any executable, which is the proper behavior for a library component what SWT is.) Enabling with system-aware DPI settings might make more sense.
Thanks for the feedback, firstly will revert the "eclipse.exe.manfest" change.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/187122
Thank you for your understanding!
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/187122 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=bb22d3af135577b23d048e05254228f899690cac
Looks like Java (In reply to Rolf Theunissen from comment #0) > In Bug 533135 dpi awareness is added for win32. However, the dpi awareness > is not consistently configured. > > This functionality is added by configuring a (external) java.exe.manifest. > The dpi awareness settings changed with the different Java versions. > > Java 8, uses dpi aware system [1], Java 9 uses dpi aware per monitor [2], > Java 11 uses dpi aware per monitor v2 (with fallback to per monitor and > system) [3]. Java11 onwards, the default manifest setting from the Java side are good enough and SWT tweaking is not required any more: https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/windows/native/launcher/java.manifest Early 4.23 we remove this altogether the way it's already proposed in bug 560195, refer below gerrit for details: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/157775
(In reply to Niraj Modi from comment #17) > Looks like Java (In reply to Rolf Theunissen from comment #0) > > In Bug 533135 dpi awareness is added for win32. However, the dpi awareness > > is not consistently configured. > > > > This functionality is added by configuring a (external) java.exe.manifest. > > The dpi awareness settings changed with the different Java versions. > > > > Java 8, uses dpi aware system [1], Java 9 uses dpi aware per monitor [2], > > Java 11 uses dpi aware per monitor v2 (with fallback to per monitor and > > system) [3]. > > Java11 onwards, the default manifest setting from the Java side are good > enough and SWT tweaking is not required any more: > https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/ > windows/native/launcher/java.manifest > > Early 4.23 we remove this altogether the way it's already proposed in bug > 560195, refer below gerrit for details: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/157775 Clearly, the per-monitor settings in the java manifest file are not the correct ones, as these result in the issue that Ed reported. SWT is not per-monitor aware, while the java manifest states that Java (AWT/Swing) is. Also, depending on the environment will only decrease consistency, not increase it.
Moving out of 4.23
