Skip to content

[Win32] Remove runtime change of process DPI awareness#3363

Open
HeikoKlare wants to merge 1 commit into
eclipse-platform:masterfrom
HeikoKlare:win32-programmatic-process-dpiawareness
Open

[Win32] Remove runtime change of process DPI awareness#3363
HeikoKlare wants to merge 1 commit into
eclipse-platform:masterfrom
HeikoKlare:win32-programmatic-process-dpiawareness

Conversation

@HeikoKlare
Copy link
Copy Markdown
Contributor

@HeikoKlare HeikoKlare commented Jun 4, 2026

SWT initialization modifies the process DPI awareness via the static initializer of the OS class. This has been implemented for DPI awareness on Windows Vista long time ago (c9bc8bf). Changing process DPI awareness programmatically is discouraged and should rather be done by the application's manifest: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setprocessdpiaware

In addition, relevant executables into which SWT is embedded (JVM, Equinox launcher etc.) already have state-of-the-art settings for DPI awareness, which even activate higher levels of DPI awareness than what the call to setProcessDPIAware (conforming to "System" DPI awareness) does. In consequence, this call has no benefit but may rather interfere with DPI awareness settings already done via the manifest.

This change thus removes the obsolete programmatic setting of process DPI awareness along with the now unused native method.

SWT initialization modifies the process DPI awareness via the static
initializer of the OS class. This has been implemented for DPI awareness
on Windows Vista long time ago. Changing process DPI awareness
programmatically is discouraged and should rather be done by the
application's manifest. In addition, relevant executables into which SWT
is embedded (JVM, Equinox launcher etc.) already have state-of-the-art
settings for DPI awareness, which even activate higher levels of DPI
awareness than what the call to setProcessDPIAware (conforming to
"System" DPI awareness) does. In consequence, this call has no benefit
but may rather interfere with DPI awareness settings already done via
the manifest.

This change thus removes the obsolete programmatic setting of process
DPI awareness along with the now unused native method.
@HeikoKlare HeikoKlare force-pushed the win32-programmatic-process-dpiawareness branch from 5848adc to 23d3655 Compare June 4, 2026 09:49
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 4, 2026

Test Results (win32)

   30 files  +    2     30 suites  +2   5m 50s ⏱️ + 5m 45s
4 704 tests +4 609  4 629 ✅ +4 534  75 💤 +75  0 ❌ ±0 
1 234 runs  +1 113  1 210 ✅ +1 089  24 💤 +24  0 ❌ ±0 

Results for commit 23d3655. ± Comparison against base commit 60e822c.

@HeikoKlare HeikoKlare marked this pull request as ready for review June 4, 2026 10:32
@Phillipus
Copy link
Copy Markdown
Contributor

In consequence, this call has no benefit but may rather interfere with DPI awareness settings already done via the manifest.

Are there any known side-effects of this in the wild?

@HeikoKlare
Copy link
Copy Markdown
Contributor Author

Are there any known side-effects of this in the wild?

No, I am not aware of any. From the API documentation, I would expect the method to "downgrade" the DPI awareness, but even though the method returns "true" (which means "success"), it does actually not change the DPI awareness (otherwise we would have already noticed at many places). The processes still run at PerMonitorV2, so it effectively seems to only upgrade if no DPI awareness is set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants