Implements DPI scaling detection and automatic UI scaling

[Nirus2000]

in memory #4115

Problem

On high-DPI displays with scaling enabled (e.g., Windows 150%, 200%, or macOS Retina), UI elements like tooltips in the Performance view were not properly sized, making text and values difficult or impossible to read.

Changes

• SWTHelper.java: Added DPI detection utilities
• SWTHelperTest.java: Comprehensive test coverage

Platform Support

• Windows: 100%, 125%, 150%, 175%, 200%, 225%, 250%, 300%, 350%, 400%
• macOS: Non-Retina (72 DPI), Retina 2x (144 DPI), Retina 3x (218 DPI)
• Linux: Standard 96 DPI base with custom scaling

First try... sooo... can anybody please test?

• MoneyTrailDataSource.java: Applied DPI scaling to tooltip rendering
• Scaled spacing and column widths for proper layout
• Ensures tooltips are readable at all scaling levels

So... @buchen
First try... sooo... can anybody please test?

• MoneyTrailDataSource.java: Applied DPI scaling to tooltip rendering

[Nirus2000]

My results:

Windows 11 --> 150% --> Missing Money

with follow settings in PortfolioPerformance.ini

-Dswt.enable.autoScale=true
-Dswt.autoScale=quarter
-Dswt.autoScale.method=nearest
-Dswt.autoScale=150

---

Windows 11 --> 150% -->All values visible... 👍🏻

without any settings in PortfolioPerformance.ini

[georgemac-labs]

@Nirus2000 happy to take a look at this on Mac, but can you tell me where in the app to find the view(s) concerned? Seems to be some feature I don't use and I can't find it.

[Nirus2000]

@georgemac-labs
Dashboard -> New Widget -> Performance calculation --> and hover effect over the monetary amounts

[georgemac-labs]

@Nirus2000 I don't see any problems on Mac, even in v0.80.4.

However, the widget also looks different from your screenshots, so maybe I'm not looking in the right place. I don't see anything that looks like the Monatliche Investitionen with letters for the months. I've tried with my personal portfolio and the Kommer sample file. Perhaps it's because neither uses an Investment Plan?

This is what I see as Performance Calculation with the Kommer file:

[Nirus2000]

@georgemac-labs
i see... hmm...
here my screenshot with the Kommer file:

you need to hover "Capital Gains" or "Earnings"... for example...

[georgemac-labs]

@Nirus2000 finally figured it out, but even with the same dates, I see different numbers – your Kommer file seems to have different data from mine!

Anyway, can't see any issue on macOS 13.7.2. However I am a few years behind the current release...

[wahlbrink]

I think the shown disappearance of text fragments at zoom level 150 is caused by a bug in SWT and should be fixed in Eclipse 2025-12:
eclipse-platform/eclipse.platform.swt@f51bb3b

[buchen]

First, here are my observations (as I am using macOS):

• The settings (swt.enable.autoScale etc.) have no effect on macOS (I understand SWT is already using the native scaling)
• The changes in the MoneyTrailDataSource add additional spacing - see screenshots below.

before this pull request

after this pull request

I am not sure if that is useful. I think the size of the screenshot should be as small as possible.

[buchen]

@wahlbrink writes:

I think the shown disappearance of text fragments at zoom level 150 is caused by a bug in SWT and should be fixed in Eclipse 2025-12:
eclipse-platform/eclipse.platform.swt@f51bb3b

Sounds like it. The size is measured, but rounded down. The label cannot be rendered in full. Because it is right aligned, the currency code shows up on the right.

@Nirus2000 can you test on your machine? You can use the latest 4.38 release candidate by using this updated fragment in the target definition:

	<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
		<repository location="https://download.eclipse.org/eclipse/updates/4.38-I-builds/I20251120-1800/"/>
		<unit id="org.eclipse.e4.rcp.feature.group" version="4.38.0.v20251120-0906"/>
		<unit id="org.eclipse.equinox.executable" version="3.8.3100.v20251111-0406"/>
		<unit id="org.eclipse.equinox.executable.feature.group" version="3.8.3100.v20251111-0406"/>
		<unit id="org.eclipse.platform.feature.group" version="4.38.0.v20251120-1800"/>
		<unit id="org.osgi.service.component.annotations" version="1.5.1.202212101352"/>
		<unit id="org.eclipse.osgi.services" version="3.12.300.v20250707-1221"/>
	</location>

[Nirus2000]

Hello @buchen
I built the build as “local dev” and got the following result:

before this pull request:

---

after this pull request
Without changes in PortfolioPerformance.ini..

---

I think...

// Apply DPI scaling for minimum column widths
int minDateWidth = SWTHelper.scalePixel(80);
int minLabelWidth = SWTHelper.scalePixel(200);
int minSharesWidth = SWTHelper.scalePixel(80);
int minValueWidth = SWTHelper.scalePixel(100);

[wahlbrink]

@buchen

		<unit id="org.eclipse.equinox.executable" version="3.8.3100.v20251111-0406"/>

triggers an error for me: "Unable to locate installable unit org.eclipse.equinox.executable/3.8.3100.v20251111-0406"
The line appears unnecessary to me ('org.eclipse.equinox.executable.feature.group' is sufficient)?

[wahlbrink]

I can no longer reproduce the problem with 2025-12.

[Nirus2000]

Hello @buchen
I removed the minimum widths, and in doing so, we almost forgot to check whether any additional information was also displayed correctly. (TrailRecord --> Messages.LabelTrailWithoutTaxesAndFees)

Here are my results:

before this pull request:

after this pull request

[buchen]

Thanks @wahlbrink and @Nirus2000 for the testing. I read this as we should update to 2026-12. The release is scheduled for 10 December. Usually, I try to give it a couple weeks to see if urgent problem occur. But the rendering with zoom factor certainly merits an early update.

And tweaking the spacing can also make sense. By default it is (5,5). With scaling that should change. I would want to check how the platform does this. I wouldn't want to touch each and every grid layout.

[Nirus2000]

Okay, what are the next steps?!

[buchen]

@Nirus2000 writes:

Okay, what are the next steps?!

First, the bug will be fixed with the Eclipse 4.38 which is to be published early December. I do not want to ship a release candidate build. So we will have to wait for that release.

Then to my understanding, the remaining material change in this pull request is to change the spacing in the grid layout. By default, this is 5x5 pixels. When scaling, it could change to 7x7 pixels. For this change alone, I would not want to add the complexity and maintenance of the SWTHelper#getScalingFactor to the code base.

On the other hand, I do not want to close the pull request just yet. It might come in handy. To better support HiDPI, I think there are multiple activities:

• SVG icons (which surprisingly make no difference yet - not sure if I am doing this right)
• set the configuration parameter (swt.autoScale, we should start by having a preference page for the users to opt in which then sets the parameter)
• understand what Eclipse does with the Enhancements of Monitor-Specific UI Scaling on Windows in the past releases and how to activate this for a RCP application

[buchen]

And one more thing: I think the HiDPI does not only apply to Windows but could also apply to Linux as well (macOS is already supported. One issue there is that the OS widgets do not always handle if the font size is increased).

[wahlbrink]

• ...Monitor-Specific UI Scaling on Windows

I have been using/testing it for PP for two weeks (wahlbrink@7b69b89):

It works well.
Until now, I only noticed one minor problem: when you move PP to a monitor with a lower resolution, the height of the toolbar of views is too large. After switching the view, the size is correct again.

Setting the property swt.autoScale.updateOnRuntime is usually sufficient, SWT then uses default values for the other settings ("quarter" for swt.autoScale).

[buchen]

@wahlbrink I plan to add an "experimental preference page" that enables this property.
I am wondering: doesn't it required to enable swt.enable.autoScaleas well?

[buchen]

Because I am not running Windows, I find it hard to wrap my head around the configuration. Playing with the virtual machine, I see the following:

• If no option (swt.enable.autoScale) is given, then SWT is scaling according to the operating system configuration. The pixel information (say when storing the column width) remains the same (e.g. columns keep the relative size). The font size is scaled relative to the operating system.
• If an option such as -Dswt.autoScale=150 is given, then the pixels are scaled relative to that size (say the operating system configuration is 200% and autoScale is 150%, then UI is roughly 25% smaller). The font size remains relative to operating system configuration (in this example the font becomes relatively bigger because the width is reduced). That appear to be the reason why the column width does not work anymore - it is the same pixel but bigger text.
• Going to the Settings -> Compatibility -> Advanced HiDPI Setting and setting this to "System" or "System (Extended)" made it worse (visually for me when on 200%), "Application" did not make a difference.
• I haven't tested with multiple monitors, because to my understanding they will have the same DPI on VirtualVM.

My 2 cents:

• Adding swt.autoScale.updateOnRuntime sounds reasonable. I'd start with an "experiment" first
• For now, I would not expose the scale factors. The scaling should be done in the operating system. And the configuration should be "application". I am not sure we should expose this configuration to the regular user (experts can do this in the ini file)
• Updating to 4.38 makes sense (and should fix the size calculation)
• Moving to SVG icons also makes sense - when testing with 300% and 400%, I had the impression it made a difference

I appreciate any comments.

[wahlbrink]

I am wondering: doesn't it required to enable swt.enable.autoScaleas well?

The property swt.enable.autoScale was replaced by swt.autoScale several years ago (https://bugs.eclipse.org/bugs/show_bug.cgi?id=493462).

[buchen]

The master branch is now updated to Eclipse 2025-12 - see 8a8911a