[Win32] Table's horizontal ScrollBar values not scaled properly on HiDPI monitors with zoom

[wtlnw]

Describe the bug
Working on a HiDPI monitor with an active zoom (of e.g. 125%) on Windows results in a Table's horizontal ScrollBar returning unscaled values for the following API calls:

• ScrollBar.getMinimum()
• ScrollBar.getMaximum()
• ScrollBar.getSelection()

While working with a zoom of 100% (no scaling), these values seem to correspond to pixels of the table's total content width (not just the visible viewport area). This results in ScrollBar.setIncrement() and ScrollBar.setPageIncrement() to become unpredictable.

To Reproduce
See below snipplet for reproduction. The snipplet simply creates a Shell with a Table having one column. It enforces the Shell to have a width of 640 pixels. The Table's width is forced to be 640 pixels through the FillLayout of the Shell. However, the Table has one single Column with a width of 1024 pixels. When you start scrolling, the very first console output you will see looks like this:

	public static void main(final String[] args) {
		final Display display = new Display();
		final Shell shell = new Shell(display);
		shell.setLayout(new FillLayout());

		// initialize to a specific width in order to set
		// the column width so that horizontal scroll bar
		// is definitely there.
		shell.setSize(640, 480);

		final Table table = new Table(shell, SWT.H_SCROLL);
		table.setHeaderVisible(true);

		final TableColumn column = new TableColumn(table, SWT.NONE);
		column.setText("Column");
		column.setWidth(1024);

		// attach a listener which will output the dimensions upon scrolling
		// to see what the total width is and what the ScrollBar values are
		table.getHorizontalBar().addSelectionListener(SelectionListener.widgetSelectedAdapter(e -> {
			final ScrollBar bar = (ScrollBar) e.widget;
			System.out.println(String.format("""
					Table {
						view-width:  %d,
						total-width: %d
					}
					ScrollBar {
						minimum:   %d,
						maximum:   %d,
						thumb:     %d,
						selection: %d
					}
					""",
					table.getSize().x, Arrays.stream(table.getColumns()).collect(Collectors.summingInt(TableColumn::getWidth)),
					bar.getMinimum(), bar.getMaximum(), bar.getThumb(), bar.getSelection()));
		}));
		
		shell.open();
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch())
				display.sleep();
		}
		display.dispose();
	}

Zoom: 100%:

Table {
	view-width:  640,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1024,
	thumb:     640,
	selection: 0
}

So, the thumb size equals the table's view port size (which make sense) and the ScrollBar's selection range is from zero to maximum - minimum - thumb, which also makes sense because that's the area missing in the view port.

Zoom: 125%:

Table {
	view-width:  622,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1024,
	thumb:     622,
	selection: 0
}

The above is weird because it takes the scaled view port width (and again uses that as thumb size) but then it uses the unscaled column width as the maximum value thus making the range of ScrollBar's selection value a weird combination of scaled thumb and unscaled width.

Expected behavior
Either the ScrollBar's values (minimum, maximum, thumb, selection, increment, pageIncrement) are always scaled to match the zoom factor or they are not, but having a mix of scaled and unscaled values is unpredictable for usage.

Environment:

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

Tested on Windows 10 and 11, both have the same problem.

Version since
SWT v3.131.0, win32.x86_64

Workaround (or) Additional context
A workaround in that specific case would be to use Win32DPIUtils.pixelToPoint() methods but these are not public API.

[HeikoKlare]

Thank you for that report. My first question is whether you face issues in a pure SWT application or if you actually use an Eclipse application and just provide the SWT snippet for reproduction. The reason for that queston is that Eclipse applications use monitor-specific UI scaling by default for a while now whereas SWT still defaults to a more simple HiDPI support (only supporting a single zoom). That particularly affects the behavior of the given snippet, as the posted values are rather what you get with that simple HiDPI support (which is different from what Eclipse applications do by default). In case you want to have the same behavior as in an Eclipse application, you need to start the snippet with -Dswt.autoScale.updateOnRuntime=true. Then you get values like these:

Table {
	view-width:  626,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1279,
	thumb:     782,
	selection: 0
}

Apart from that, I am not completely sure how/why the values in the original post are considered incorrect. Since the snippet is executed with default settings, SWT scales all values (except font sizes coming from the OS) at 100% even on 125% monitor. That's why you see the same values in terms of pixels and logical points. Unfortunately, I cannot see the difference between 100% and 125% at all, they both show the same values (the ones you posted for a 125% monitor).

When taking a look at the ScrollBar implementation and it's consumers, it seems as if there is no custom logic to initialize the minimum/maximum values etc. for them, but they seem to be initialized by the operating system. And those values always seem to have been conforming to the table size in pixels and not in logical points. This can be seen when executing the snippet on a monitor with 175% or above. Then I get:

Table {
	view-width:  628,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   2047,
	thumb:     1255,
	selection: 0
}

So I wonder if this is new behavior or if it rather gets notices now with the monitor-specific scaling in Eclipse application as they are affected by the pixel/point inconsistent not only at 175% and above but already at 125%.

Version since
SWT v3.131.0, win32.x86_64

Just to run into the right direction: do you know that the behavior was different on 3.130.0 and below and that it still persists in the current SWT state?

[wtlnw]

Thanks for the quick response!

To answer your first question: I'm observing this behavior with both, an eclipse (via plugin) and a standalone SWT application. Thanks to your hint regarding Dswt.autoScale.updateOnRuntime=true switch for the SWT application, the behavior is now consistently inconsistent in exactly the same manner for both. ;)

To include the updateOnRuntime flag in test findings, I see the following behavior (consistently for ecilpse and standalone):

Zoom 100%:

Table {
	view-width:  640,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1024,
	thumb:     640,
	selection: 0
}

Zoom 125% (updateOnRuntime=false):

Table {
	view-width:  622,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1024,
	thumb:     622,
	selection: 0
}

Zoom 125% (updateOnRuntime=true):

Table {
	view-width:  626,
	total-width: 1024
}
ScrollBar {
	minimum:   0,
	maximum:   1279,
	thumb:     782,
	selection: 0
}

What I tried to point out is that while the table's viewport and total width are reported in display units (or logical units as you call them), the scroll bar's values are in pixels. Thus, taking a scroll bar's selection and using it for offset computations or changing the scroll bar's increment/pageIncrement requires tranformation from pixels to display units and vice versa.

Sorry, if I was being confusing. It's not about the value magnitudes, it's about the unit. With zoom=125% && updateOnRuntime=false the values are still wrong because they are in pixels. So, if I take ScrollBar.getSelection() and use it to update the location of a control, the result is unexpected because the control's location method expects display units, not pixels.

As of the exact version, the behavior actually changed in 3.129.0, while 3.128.0 worked as expected. But the impact seems to be more severe with 3.131.0. Maybe because some other APIs started to require display units instead of pixels or something? I don't know.

[HeikoKlare]

Thank you for the additional information. From my current understanding, the issue probably became more severe with monitor-specific scaling being available (and enabled by default) as the underlying issue/behavior (scrollbar value being in pixels instead of points) has always existed.
If you take older SWT versions, you will probably experience the same issue with monitor zooms of 175% and above (as then the "effective" zoom is 200% whereas with 150% and below the effective zoom was 100%). This is because of the default auto-scale mode previously being "int200", which rounded the actual zoom to either 100% or 200%. So to me it seems as if you rely on behavior that was never guaranteed, though I don't want to say that your expectation is wrong but just that the implemented actually never fulfilled it.

So either the SWT behavior needs to be revised to make scrollbar values conforming to control sizes (which could break other consumers that rely on the existing behavior of this not being the cae) or consumers have to translate the scollbar values to control values, i.e., convert the scrollbar pixel value into a percentage and convert that percentage back to the view's composite point coordinates.

[wtlnw]

You're right, the ScrollBar API doesn't explicitly state that, so I guess my expectations were wrong here. Thanks for the heads-up! I think that the best way to address this would be to adjust the API description of the ScrollBar class to hint what the values actually are. Other than that, this issue can be closed.

Thanks!