Cursors not correctly sized when using swt.autoScale on a HighDPI screen.

[ptziegler]

I'm using a monitor with 150% zoom. Now consider the following snippet:

package test;

import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.Cursor;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.ImageData;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;

public class Snippet {
        public static void main(String[] args) {
                System.setProperty("swt.autoScale", "200");
                Cursor cursor = new Cursor(null, getImageData(100), 0, 0);

                Shell shell = new Shell(SWT.NO_TRIM);
                shell.setSize(100, 100);
                shell.setCursor(cursor);
                shell.setBackground(new Color(0, 255, 0));
                shell.open();

                Display display = shell.getDisplay();
                while (!display.isDisposed()){
                        display.readAndDispatch();
                }
                cursor.dispose();
        }

        private static ImageData getImageData(int zoom) {
                Image image = new Image(null, 50, 50);
                try {
                        GC gc = new GC(image);
                        gc.setBackground(new Color(255, 0, 0));
                        gc.fillRectangle(0, 0, 50, 50);
                        return image.getImageData(zoom);
                } finally {
                        image.dispose();
                }
        }
}

Expectation: The cursor should always take up 25% of the shell.

SWT 3.128.0 (2024-12), exactly right:

SWT 3.129.0 (2025-03), way too big:

SWT 3.130.0 (2025-06), too big:

SWT 3.131.0 (2025-09), too small:

[ptziegler]

Addendum: If I remove the "swt.autoScale" property, I get this:

SWT 3.131.0/3.130.0 (2025-09/2025-06)

Note: This case still works with the 2025-03. Since then, the actual size of the cursor is either multiplied or divided by the device zoom, even though the underlying shell is not scaled.

[HeikoKlare]

We will have a look into whether we can restore the original behavior in a proper way. I quickly debugged the code (with the current master state) and found that it does not seem to be related to how the Image class behaves, as the delivered image data is always at zoom 100 with size (50, 50), just as expected. It's rather up to how the cursor is set, as that code uses the native zoom (150 in the example), which does not fit to the manually defined device zoom value (200), which is why the cursor becomes smaller:

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Control.java

Lines 5476 to 5488 in 2ddc1ad

	LRESULT WM_SETCURSOR (long wParam, long lParam) {
	int hitTest = (short) OS.LOWORD (lParam);
	if (hitTest == OS.HTCLIENT) {
	Control control = display.getControl (wParam);
	if (control == null) return null;
	Cursor cursor = control.findCursor ();
	if (cursor != null) {
	OS.SetCursor (Cursor.win32_getHandle(cursor, getNativeZoom()));
	return LRESULT.ONE;
	}
	}
	return null;
	}

It has last been changed here:

• Do not use DPIUtil.getNativeDeviceZoom() to get the cursor handle #2057 #2090

But the change looks as if the functionality must have already been broken before. So this is also related to:

• Custom cursor size is doubled with Eclipse 4.35 #2057

This is really a mess because all these different scaling options are not properly tested. And I have to admit that we did not consider the swt.autoScale=ZOOM_LEVEL option that well. It's a bit strange anyway. I would understand that option if it took the font size into account as well (as it would behave similar to an overall UI scaling then), but just scaling the UI without the fonts is a bit pointless.

Addendum: If I remove the "swt.autoScale" property, I get this:

SWT 3.131.0/3.130.0 (2025-09/2025-06)

I cannot reproduce this one. With 150% monitor scaling and with default auto-scaling settings, I get the "expected" behavior (i.e., a cursor taking 25% of the area of the shell) for the given snippet.

[ptziegler]

And I have to admit that we did not consider the swt.autoScale=ZOOM_LEVEL option that well. It's a bit strange anyway. I would understand that option if it took the font size into account as well (as it would behave similar to an overall UI scaling then), but just scaling the UI without the fonts is a bit pointless.

As I mentioned in my 2nd comment, the issue also appears when swt.autoScale isn't used. And that's also what made me aware of this issue in the first place, because I noticed the cursor being blurry, even though I wouldn't have expected any scaling.

That it also appears when explicitly setting the auto-scaling was then something I only noticed because I then started playing around with the SWT settings, to see whether this affects the cursor as well.

I cannot reproduce this one. With 150% monitor scaling and with default auto-scaling settings, I get the "expected" behavior (i.e., a cursor taking 25% of the area of the shell) for the given snippet.

That is weird... I just tried it again on a different machine and the issue still appears. Even with the latest SWT version:

As a side-note: If autoScale.updateOnRuntime is enabled, the cursor is correctly sized.

[HeikoKlare]

I cannot reproduce this one. With 150% monitor scaling and with default auto-scaling settings, I get the "expected" behavior (i.e., a cursor taking 25% of the area of the shell) for the given snippet.

That is weird... I just tried it again on a different machine and the issue still appears. Even with the latest SWT version:

Sorry, my fault. Eclipse assigned the new snippet to some existing run configuration that had monitor-specific scaling enabled. Note that the actual cause of making the cursor size correct is not the monitor-specific scaling but the auto scale mode being set to quarter implicitly, which makes DPIUtil's native zoom and device zoom equal. It goes back to the same line of code I posted above. When changing that code to ensure that not the native zoom is taken but that one is mapped to an according device zoom (be it with default integer200 scaling or with a fixed scale value), the issue is fixed. But hat needs to be investigated thoroughly to find a solution that fits for every combination of settings.