[Refactor] Moving methods from Win32DPIUtil to DPIUtil for autoscaling

[ShahzaibIbrahim]

Workbench needs few methods from DPIUtil that were only present for Win32. Keeping the functionality for Win32DPIUtil as is, just making them available for DPIUtil.

[github-actions]

Test Results

  111 files   -  7    111 suites   - 7   19m 27s ⏱️ + 3m 44s
4 596 tests  - 56  4 580 ✅  - 55  15 💤  - 2  1 ❌ +1 
  282 runs   - 56    281 ✅  - 53   1 💤  - 3  0 ❌ ±0 

For more details on these failures, see this check.

Results for commit 93d5d62. ± Comparison against base commit 65ec239.

This pull request removes 56 tests.

AllWin32Tests ImageWin32Tests ‑ testDisposeDrawnImageBeforeRequestingTargetForOtherZoom
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ testImageDataForDifferentFractionalZoomsShouldBeDifferent
AllWin32Tests ImageWin32Tests ‑ testImageShouldHaveDimesionAsPerZoomLevel
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromCopiedImage
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromImageForImageDataFromImage
AllWin32Tests TestTreeColumn ‑ test_ColumnOrder
…

This pull request skips 1 test.

org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_setUrl_remote_with_post

♻️ This comment has been updated with latest results.

[HeikoKlare]

I would be in favor of doing such a change more incrementally. Obviously, there is code in Platform UI depending on (internal) methods of DPIUtil. Moving them to another class means that Platform UI code becomes incompatible once we merge the SWT PR and if we merge the Platform UI PR at the same time (without knowing if it works as the CI will fail) will make Platform UI builds fail until the next I-Build.

Thus, in such a case a multi-step transition should be made by refactoring and maybe adding methods while still keeping the old ones (as delegates), then adapt the consumers (such as Platform UI) and once that is done remove the delegates that became obsolete.

It also seems like the AutoScaling class and DPIUtil would be highly mutually dependent. This could be an indicator that splitting them up is not a good idea. In any case, AutoScaling seems like it disposes much new public API that we will tie ourselves to. I know that I proposed to make some its functionality API, but seeing it I am not so sure anymore whether we should really do it or better keep it internal (like with DPIUtil) and access the internal API from Platform UI for now. At least, whatever we make public should be as lean as possible and in my opinion we should definitely not make something like an autoscale mode publicly accessible.

[ShahzaibIbrahim]

As suggested, I have kept the methods in DPIUtil class. This PR now only moves few of the method in DPIUtil as these will be required to me in the workbench for subsequent PR: eclipse-platform/eclipse.platform.ui#3475.

The idea is to limit monitor specific for both SWT and eclipse products with compatible autoscaling methods.

[HeikoKlare]

This makes the proposed change not a refactoring but will actually further restrict the supported auto-scale modes. To keep this a refactoring that behavioral change should be reverted. The same is indicated by the need to modify a test.

[ShahzaibIbrahim]

I have created another PR that is not related to refactoring: #2771. This PR now only refactor some code to move it to DPIUtils.

[HeikoKlare]

@akurtakov this PR is not yet ready to be merged, but at least your specific request for changes was resolved, wasn't it?

My concern has been adressed.

[HeikoKlare]

If I see correctly, with one of the recent changes the isSetupCompatibleToMonitorSpecificScaling() method was removed from DPIUtil:
https://github.com/eclipse-platform/eclipse.platform.swt/compare/59dcd79dbbac1b225456de45d862112be58ad0fe..030948f5d401d2640cd0ca0ec8bf6d53ff039dec

However, if I understand this change correctly, it prepares for:

• eclipse-platform/eclipse.platform.ui#3475

But that PR requires exactly that method.

So shouldn't the method be provided with this PR? Otherwise I don't the point of it.

[ShahzaibIbrahim]

I have made 3 PRs in total.

1. This is the first PR (just the refactoring)
2. The method you mention is now in Limit autoscale mode to quarter and exact only #2771 (Preparatory PR for the one in Platform
3. The last PR (Platform)

[HeikoKlare]

I have made 3 PRs in total.

1. This is the first PR (just the refactoring)
2. The method you mention is now in Limit autoscale mode to quarter and exact only #2771 (Preparatory PR for the one in Platform
3. The last PR (Platform)

But that does not fit to the order we need:

1. Adapt Win32DPIUtil/DPIUtil (without any behavioral changes), so that we can process Limit monitor-specific scaling to supported autoscale modes eclipse.platform.ui#3475
2. Process Limit monitor-specific scaling to supported autoscale modes eclipse.platform.ui#3475
3. Limit autoscale modes to quarter/exact for monitor-specific scaling (do be done for next release)