[Win32] Broken compatibility with swt.autoScale=false

[tmssngr]

Describe the bug
Because of serious painting problems on Windows we have to set swt.autoScale to false and use display.getDPI() to (indirectly) find out the zoom level. However, build c66545b broke this compatibility.

To Reproduce
Run this snippet

import org.eclipse.swt.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class AutoScaleFalseTest {

	public static void main(String[] args) {
		System.getProperties().putIfAbsent("swt.autoScale", "false");

		final Display display = new Display();

		final Shell shell = new Shell(display);
		shell.addListener(SWT.Paint, event -> {
			final String deviseZoom = System.getProperty("org.eclipse.swt.internal.deviceZoom");
			event.gc.drawString(deviseZoom, 0, 0);
			final Point dpi = display.getDPI();
			event.gc.drawString(String.valueOf(dpi), 0, 30);
		});

		shell.setSize(400, 300);
		shell.open();

		while (!shell.isDisposed()) {
			if (!display.readAndDispatch()) {
				display.sleep();
			}
		}

		display.dispose();
	}
}

on commit 40b4fc6 and on commit c66545b on a system with 4k monitor set to 150% zoom level. The first will report correctly 144 dpi, the latter 96dpi.

Expected behavior
If swt.autoScale is set to false, no autoscaling must happen.

Screenshots
Commit 40b4fc6:

Commit c66545b:

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)
   We are Win11 24H2, but this should not have any influence.

Workaround (or) Additional context
Nothing known.

[akoch-yatta]

There is already PR #1646 that should restore the previous behavior

[tmssngr]

Yes, thanks, this fixes the problem for me.