[win32] Use deviceZoom in single zoom mapper

[akoch-yatta]

This PR replaces the usage of the zoom attribute in methods in the SingleZoomCoordinateMapper that translate Point and Rectangle from and to display coordinates to use DPIUtil.getDeviceZoom() instead. As each widget inherits its zoom from DPIUtil.getDeviceZoom() when the SingleZoomCoordinateMapper is involved, the behavior is not changed in most scenarios. but this PR fixes the scenarios, if a widget is scaled to a different zoom, e.g. by utilizing widget.setData("AUTOSCALE_DISABLED", true) the current implementation will break all conversions. One important factor in the CoordinateMapper implementation is to have a consistent translation from and to display coordinates. In the MultiZoomCoordinateSystemMapper this is achieved by extracting the Monitor (zoom) out of the coordinate to translate. In SingleZoomCoordinateMapper, the implementation was not consistent yet, as e.g. in SingleZoomCoordinateMapper#getCursorLocation or SingleZoomCoordinateMapper#setCursorLocation DPIUtil.getDeviceZoom() is already used.

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   29m 57s ⏱️ + 2m 40s
 4 425 tests ±0   4 408 ✅ ±0   17 💤 ±0  0 ❌ ±0 
16 746 runs  ±0  16 619 ✅ ±0  127 💤 ±0  0 ❌ ±0 

Results for commit 1b3ae75. ± Comparison against base commit 9baef58.

♻️ This comment has been updated with latest results.

[HeikoKlare]

The change definitely makes sense. As a follow up, we should remove the obsolete zoom parameter of those methods.

I wonder if the mapMonitorBounds() method is not affected in the same way?
One consumer is the Display#getMonitor() method:

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

Line 2233 in 9baef58

monitor.setBounds(coordinateSystemMapper.mapMonitorBounds(boundsInPixels, autoscaleZoom));

Shouldn't those bounds also be scaled according to the device zoom instead of the zoom of that specific monitor in case of a single zoom mapper? Otherwise with a 100% primary monitor and a 200% secondary monitor, I would expect the bounds of the secondary monitor, scaled with 200% instead of 100%, to be wrong.

[akoch-yatta]

The change definitely makes sense. As a follow up, we should remove the obsolete zoom parameter of those methods.

I wonder if the mapMonitorBounds() method is not affected in the same way? One consumer is the Display#getMonitor() method:

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

Line 2233 in 9baef58

monitor.setBounds(coordinateSystemMapper.mapMonitorBounds(boundsInPixels, autoscaleZoom));

Shouldn't those bounds also be scaled according to the device zoom instead of the zoom of that specific monitor in case of a single zoom mapper? Otherwise with a 100% primary monitor and a 200% secondary monitor, I would expect the bounds of the secondary monitor, scaled with 200% instead of 100%, to be wrong.

Yes, I thought about that, but wanted to come up with a test for that. But I think we will need to adapt those as well.

[HeikoKlare]

Yes, I thought about that, but wanted to come up with a test for that. But I think we will need to adapt those as well.

Alright, we can also keep that for a separate PR and merge this one as is.

[akoch-yatta]

I would propose to do that separately and merge this PR as is. I will test the original behavior to add a proper test set for mapMonitorBounds to ensure the correct behavior.