Tackle limitation of point coordinate system

[akoch-yatta]

There are some scenarios, e.g. with detached views in the IDE, where point to pixels conversion lead to unexpected results:

Scenario 1 (e.g. detached preview)

Fetch a point are rectangle on one monitor and change it programmatically to another monitor (with a different zoom) before using it again:

Point l = shell.getLocation();
l.x += 30;
shell.setLocation(l);

Scenario 2 (e.g. Eclipse view D&D)

E.g.
Control::getBounds().contains(getCursor)

Scenario 3 (Maximized window)

getBounds with maximized windows -> getBoundsInPixel gives position with x/y shifted by 8 outside of monitor

Follow-up Actions

• Evaluate whether Command palette has the wrong size when rescale at runtime is active #184 still appears

[akoch-yatta]

Improved by PR #1524

[akoch-yatta]

As discussed in the daily, we will rediscuss this issue and possible solutions

[amartya4256]

After investigating this issue, we had these options for fixing/redesigning the coordinate system:

• Having one zoom level for the global coordinate space:

1. Having 100% for all monitor: The problem that I noticed was in the overlay during the drag and drop not being placed in the right position because of scaling issue.

2. Having pixels/absolute positioning for all monitors: The main problem with this method so far was that we need the clients to adapt to provide the pixels value especially for set bounds and location for Shells.

• Having a Coordinate System with gaps: The problem is the gap. If a point is placed in the gap, how should we treat it in terms of scaling.

We have further created some tests to find out what problems lie in this approach: eclipse-platform/eclipse.platform.swt#1699

[HeikoKlare]

2. The main problem with this method so far was that we need the clients to adapt to provide the pixels value especially for set bounds and location for Shells.

I do not fully understand this point: aren't setBounds() and setLocation() (usually) called with some modified values that have previously been retrieved from getBounds()/getLocation()? Or to phrase it differently: are there any sources of objects passed to those setters that have (initially) been explicitly defined in points rather than whatever the according getters yield?

[amartya4256]

Here are the different Coordinate system specifications along with the major problem associated with them:

Having one zoom level for the global coordinate space:
Having global coordinate space in pixels:

• 2 different contexts cause the problem of drag and drop not working inside
  

Having a different zoom level for each monitor with Gap:

• Points in the gap are misevaluated because of the absense of zoom context

Having a different zoom level for each monitor with overlapping monitors

• ambiguous points

[amartya4256]

According to the last discussion, the plan is to provide zoom context to the rectangles and points which are used in the mappers, consume it while converting from points to pixels and validate if this fixes the bugs in the current MultiZoomCoordinateSystemMapper.

[amartya4256]

The shell can be created while having another shell as its parent. It means if a shell is on a monitor with a different zoom level, it might still receive a DPI_CHANGED callback from its parent from the different monitor. We need to verify if it can lead to any unprecedented behaviour.

[fedejeanne]

This issue is In Review but the linked PRs are inactive. Is eclipse-platform/eclipse.platform.swt#1711 related to this one?

[HeikoKlare]

Also related to this (but does not completely resolve this):

• Fixed Shell::setBounds scaling eclipse-platform/eclipse.platform.swt#1733