Adapt Win32 launcher DPI awareness and autoscale configuration

[HeikoKlare]

Eclipse products use monitor-specific scaling by default for several releases now. The products apply that scaling to the window created for the workbench and adapt the DPI awareness for the UI thread of that window. The whole application process is still executed in "System" DPI awareness (used for the whole application before monitor-specific scaling was available) as defined by the Equinox launcher's manifest. Since SWT also still used non-monitor-specific scaling as default, the splash screen initialized by the Equinox launcher was still processed without monitor-specific scaling (with some tweaks in the Workbench implementation to make that work as expected).

With SWT using monitor-specific scaling on Windows by default (see eclipse-platform/eclipse.platform.swt#2955), a fitting process DPI awareness ("PerMonitorV2") must be used by the Equinox native launcher to have a proper splash screen experience. In addition, this will adapt the Equinox launcher to the current defaults of Eclipse products and of the JDK itself (which by default uses PerMonitorV2 as well).

As with monitor-specific scaling the default swt.autoScale value on Windows changes from "integer" to "quarter", this behavior is also adapted in the eclipseWin.c to align with the implementation in SWT's DPIUtil. In case monitor-specific scaling is deactivated via system property, the swt.autoScale value still defaults to "integer", which is also reflected in this change to conform to SWT behavior.

Question

A consequence of this will be that if using a new Equinox release together with an older than the upcoming SWT and/or Eclipse UI release, the autoscaling of the splash screen may be inconsistent. This is always the case when autoscaling adaptations are made as they implicitly have to be aligned (as also documented in eclipseWin.c). Just recently, a missing alignment for several years was fixed (#1213).
Is there any intended way to ensure the usage of consistent SWT and Equinox (and/or Platform UI) versions? Since I don't see that there are any specific version dependencies (in particular, I don't think that anything in Platform explicitly depends on the Equinox launcher), the only possibility I see is to define a system property in the Equinox launcher that is ready by the Platform to identify if an adapted version of Equinox is used, so that the (splash screen) behavior can be adapted. That might be a system property specific to the actual change or some kind of version of the Equinox autoscaling behavior that the Platform could adapt to. But I am also not sure if it is worth the effort or whether it is safe to assume that people should use consistent Equinox/SWT/Platform versions for their products.

Opinions on this or input on how this is intended to work are highly appreciated (maybe @akurtakov?).

Since we plan to merge the SWT adaptation for 2026-03 M2, it would be great to have the according adaptation of the Equinox launcher as well, such that everything stays consistent.

How it looks

The change is difficult to fully capture in a video:

• It particularly improves the appearance when moving the splash from one monitor to another with a different zoom
• It particularly improves the appearance of more complex splash screens than the one used by Eclipse itself (i.e., with more controls in it).

Still, the following captures at least demonstrate that the splash screen and contained control sizes now properly fit to the monitor scale and to each other.

Before

After

[akurtakov]

This is inconsistency if people merge bundles from different releases and while this will be a highly visible one it would hardly be the only one. Maybe one can find a low enough bundle that depends on both launcher and swt and ensure the version requriements are in sync there?

[HeikoKlare]

This is inconsistency if people merge bundles from different releases and while this will be a highly visible one it would hardly be the only one.

Do I understand correctly that you mean that you need to use consistent versions (i.e., from the same Eclipse release) for Equinox, SWT and Platform anyway, as you will run into problem otherswise, such that it's okay to adapt Equinox and SWT together even without an explicit dependency?

Maybe one can find a low enough bundle that depends on both launcher and swt and ensure the version requriements are in sync there?

That would be nice, but I did not find any dependency to the launcher within the SDK at all.

[akurtakov]

This is inconsistency if people merge bundles from different releases and while this will be a highly visible one it would hardly be the only one.

Do I understand correctly that you mean that you need to use consistent versions (i.e., from the same Eclipse release) for Equinox, SWT and Platform anyway, as you will run into problem otherswise, such that it's okay to adapt Equinox and SWT together even without an explicit dependency?

Yes, minimal versions in manifests are not updated everytime an API or behavior change happens somewhere. So best bet is to use versions from same Eclipse release.

[github-actions]

Test Results

  846 files  ±0    846 suites  ±0   1h 53m 39s ⏱️ + 2m 51s
2 234 tests ±0  2 185 ✅ ±0   49 💤 ±0  0 ❌ ±0 
6 702 runs  ±0  6 553 ✅ ±0  149 💤 ±0  0 ❌ ±0 

Results for commit 7f2972b. ± Comparison against base commit 953081f.

♻️ This comment has been updated with latest results.

[HeikoKlare]

Thank you for the feedback. So from my perspective this PR would be ready for merge together with eclipse-platform/eclipse.platform.swt#2955. I have tested the two together (with a new eclipse.exe and launcher .dll locally generated and embedded into the I20260121-0020 build). I have added according explanations and some screen captures to the initial PR post.

@akurtakov Is there any chance we can bring this together with the SWT change in M2 (though I know you cannot test this on Windows)? M3 would feel too late for such a chance, thus we would otherwise have to wait for 2026-06.

[akurtakov]

We can merge it when you say it's ready unless someone objects.

[HeikoKlare]

Thank you! From our side this one is ready, so you can merge whenever you want. I will merge eclipse-platform/eclipse.platform.swt#2955 right after this to ensure that we stay as much consistent as possible. We will then test everything thoroughly again with tomorrow's I-Build and in case we find anything, we will follow-up on that.

[vogella]

I merge this, as one of my clients is also affected by this and M2 is soon.