Use monitor-aware coordinates in multi-zoom coordinate system

[amartya4256]

This PR contributes to the use of MonitorAware Points and Rectangles for the translation between points and pixels coordinates in the Display Coordinate System. Since the Display Coordinate System can have different scales (zoom) in different area, it is designed to be not continuous in the points coordinates. Hence when we manipulate the coordinates of a Point or a Rectangle object, it might end up in a region which is between the 2 monitors in the point coordinate system, which we consider a gap. So, we need the context of the monitor on which those points and rectangles were created in the first place to evaluate the scaling factor. If the context is not available or the coordinates were updated to an irrelevant value, a fallback method tries to evaluate the right monitor for the coordinates and evaluates the scaled value with that.

Contributes to #62 and #127

[github-actions]

Test Results

   494 files  ± 0     494 suites  ±0   9m 17s ⏱️ -34s
 4 330 tests + 4   4 317 ✅ + 9   13 💤  -  5  0 ❌ ±0 
16 568 runs  +32  16 460 ✅ +72  108 💤  - 40  0 ❌ ±0 

Results for commit 9a1c825. ± Comparison against base commit d441a95.

This pull request removes 6 and adds 10 tests. Note that renamed tests count towards both.

org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translatePointInGapBackAndForthShouldBeTheSame(CoordinateSystemMapper)
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapBackAndForthShouldBeTheSame(CoordinateSystemMapper)
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapPartiallyInRightBackAndForthShouldBeTheSame(CoordinateSystemMapper)
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPixelsOutisdeMonitorsBackAndForthShouldBeTheSame(CoordinateSystemMapper)
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPointsInBothMonitorsPartiallyBackAndForthShouldBeTheSame(CoordinateSystemMapper)[1]
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPointsInBothMonitorsPartiallyBackAndForthShouldBeTheSame(CoordinateSystemMapper)[2]

org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translatePointInGapBackAndForthInMultiZoomShouldEndInsideTheSameMonitor
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translatePointInGapBackAndForthInSingleZoomShouldBeTheSame
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapBackAndForthInMultiZoomShouldBeInMonitorBounds
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapBackAndForthInSingleZoomShouldBeTheSame
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapPartiallyInRightBackAndForthInMultiZoomShouldBeInside
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInGapPartiallyInRightBackAndForthInSingleZoomShouldBeTheSame
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPixelsOutisdeMonitorsBackAndForthShouldBeTheSame(CoordinateSystemMapper)[1]
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPixelsOutisdeMonitorsBackAndForthShouldBeTheSame(CoordinateSystemMapper)[2]
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPointsInBothMonitorsPartiallyBackAndForthInMultiZoomShouldNotEndUpInGap
org.eclipse.swt.widgets.CoordinateSystemMapperTests ‑ translateRectangleInPointsInBothMonitorsPartiallyBackAndForthInSingleZoomShouldBeTheSame

♻️ This comment has been updated with latest results.

[fedejeanne]

@amartya4256 I see this PR is a WiP (based on the commit text), which is fine for me, but please add some description to the PR (the issue that is fixed, intended result, how to test it, etc).

For the moment I can only do an initial review of the coding standards and so on.

[fedejeanne]

I played around a bit with it and this is what I found

When rescaling at runtime is deactivated

• Moving the workbench window between 2 monitors with different zoom rescales the menu bar according to the zoom of the monitor.

IIRC this is expected so I do not consider it a bug.

When rescaling at runtime is activated

No findings

[HeikoKlare]

No testing and in-depth review from my side so far, but at least one important point from my side: please mark the new classes as "not API" (i.e., "noreference"), as we should not make them public API (at least for now).

Please also improve the commit message to shortly explain the reasons for the change and what it does, so that people can later on generally understand what the commit does. Please also add that commit description to the PR description, in the based case with some how-to-test information.

[fedejeanne]

Looks better, I only found some unnecessary empty lines.

Let me know when this PR is ready to be tested again. If you (plan to) make more changes please don't squash the commits so I can review better. You (or I) can squash the commits once the PR has been approved by me and @HeikoKlare

[fedejeanne]

I tested and found this:

When rescaling at runtime is deactivated

• The size of the checkboxes and radio buttons in the Preferences reacts to zoom changes.

This is on the 100% monitor:

To reproduce:

• Start Eclipse in 200% monitor
• Open Preferences (it should open in the 200% monitor)
• Move Preferences dialog to the 100% monitor

When rescaling at runtime is activated

• It is still difficult to (re)attach views when the workbench window spans across 2 monitors (Corner case!)

In the video you can see that:

• I wasn't able to detach the editor in my 1st attempt
• Once detached, I could only reattach it on the 200% monitor (on the left). For your reference, the border between both monitors is right in the middle of the "Navigate back" (arrow)
  

My setup

• 100% Monitor on the right
• 200% Primary monitor on the left.

Prioritization

I can live with both issues so I suggest we merge this PR and leave the findings for another release. @HeikoKlare WDYT?

[HeikoKlare]

Is the issue with rescaling at runtime being deactivated really an issue introduced by this PR? I don't see how this could be related, so would be good to check that. Otherwise it might be an independent regression for which we need to open an issue and address separately as soon as possible.

[amartya4256]

When the rescaling at runtime is deactivated it still uses the old singlezoom mapper. So I don't think that this PR could have caused this issue.

[fedejeanne]

It's not --> vi-eclipse/Eclipse-Platform#191

[HeikoKlare]

@amartya4256 can you please update the commit message as requested in #1711 (review)?

Please also improve the commit message to shortly explain the reasons for the change and what it does, so that people can later on generally understand what the commit does. Please also add that commit description to the PR description, in the based case with some how-to-test information.

[HeikoKlare]

Some minor comments regarding documentation of new API.

[HeikoKlare]

Thank you, @amartya4256!
The changes now look fine to me. I have also tested the changes and found the behavior of the multi-zoom coordinate mapping much better now. It's only corner cases (right at the border between two monitors with different scalings) that sometimes behave a bit "unexpected", but at least it behaves rather "consistently" (e.g., regarding a preview of a detach operation and the final result). And those corner cases are not easy to resolve anyway, so it's fine like it is. In particular, dragging things to another monitor now behaves eben better than without monitor-specific scaling, where, for example, a detach operation moved to another monitor with different zoom value leads to unexpected positioning.

In addition, this change is safe in the sense that it only affected the multi-zoom coordinate system mapper, which is used by the experimental monitor-specific scaling mode on Windows. So no effects regarding existing behavior of "ordinary" functionality are to be expected.

With recent change 7a58782, I adapted the equals/hashcode implementations for Point/Rectangle and MonitorAwarePoint/MonitorAwareRectangle, as otherwise they would not take the monitor into account.