`MonitorHandle::position` and `MonitorHandle::size` metrics are unclear

[madsmtm]

Window::outer_position, MonitorHandle::position and WindowEvent::Moved is fundamentally broken on macOS.

Desktop/window coordinates are internally closer to a LogicalPosition, but since the return type of these is PhysicalPosition, we convert the position using the monitor's scale factor, which is incorrect since it assumes that all monitors have that scale factor.

To illustrate the issue, imagine three monitors configured to be next to each other like this:

[                   ]    [                  ]    [                   ]
[         1         ]    [         2        ]    [         3         ]
[ logical=1920x1080 ]    [ logical=1280x800 ]    [ logical=2560x1440 ]
[  scale_factor=2   ]    [  scale_factor=1  ]    [  scale_factor=1   ]
[                   ]    [                  ]    [                   ]

The output of monitor.position().x (that is, the x desktop/window-coordinate) would then be:

	Desired physical	Desired logical	macOS API	Other platforms
Monitor 1	0	0	0	0
Monitor 2	1920 * 2	1920	1920	1920 * 2 maybe?
Monitor 3	1920 * 2 + 1280	1920 + 1280	1920 + 1280	1920 * 2 + 1280 maybe?

[madsmtm]

I can see a few ways of fixing this:

1. Make these methods return Position instead
2. Create a cursed helper function that fetches all monitors and computes the actual physical position by constructing a graph of bordering monitors. This requires that monitors are always bordering each other, which might not always hold?
3. Create a new type like DesktopPosition, which has conversion methods to/from Position with relevant documentation. This would also help separate "position on desktop" from "position in window"
   • Ideally we should probably have both InnerPosition and OuterPosition, and each of these should have variants Physical, Logical, PhysicalDelta and LogicalDelta. And the same for Size. But that also seems like overkill.

[dhardy]

Without knowing anything about the size or scale factors of the monitors in your example above, it's not useful. I presume the sizes listed are physical pixels but they could even be logical pixels.

All three of these APIs, Window::outer_position, MonitorHandle::position and WindowEvent::Moved use PhysicalPosition<i32>. If I understand correctly, PhysicalPosition is designed to count physical pixels, but when multiple monitors with different scaling factors are involved, this is meaningless (which is presumably why both Android and Wayland don't support the first function).

There is essentially only three things these methods could do:

1. Report position within a backing pixel buffer spanning all screens. This is assuming such a thing exists, which it very likely doesn't (except maybe X11?). Completely useless, I think.
2. Report position within the "virtual desktop" in logical pixels. This may not be a simple rectangle. It may not even be reported by all platforms (to be investigated, but notes on the Wayland API indicate that it may be acceptable for the server not to report monitor location correctly).
3. Some backend-specific encoding (probably just logical pixels) of window position, to allow apps to save & restore window position.

So, these should probably all report a LogicalPosition instead?

[madsmtm]

Without knowing anything about the size or scale factors of the monitors in your example above, it's not useful. I presume the sizes listed are physical pixels but they could even be logical pixels.

Apologies, I've updated the example to hopefully make it more clear.

Does winit even report the size of the virtual desktop?

Nope, but I guess you could calculate it fairly easily by collecting all MonitorHandles, and looking at their .position and .size.

So, these should probably all report a LogicalPosition instead?

I just sorta assumed the macOS impl was in the wrong here, but if it's the case that all platforms actually use logical pixels, then the problem is definitely also solvable that way.

---

In any case, an important thing is that things like Window::set_outer_position(monitor.position().into()) should continue to work.

[dhardy]

Did you mix up physical / logical in your table above?

From the winit DPI docs:

Winit’s PhysicalPosition / PhysicalSize types correspond with the actual pixels on the device, and the LogicalPosition / LogicalSize types correspond to the physical pixels divided by the scale factor.

So monitor 2's x coordinate should be 1920 physical or 960 logical.

Window::set_outer_position(monitor.position().into()) should continue to work.

Sure. This example is nice and simple, but there are several ways it could get complicated:

• The user adjusts the scale factor of monitor 1. The physical position of monitor 2 stays unchanged, but the logical position changes (assuming the two are touching).
• The compositor gives the app an integer scale factor then down-scales to the user's chosen scale factor (i.e. what Wayland did/does before fractional scaling). What does Winit mean by "physical pixels" in this case — the buffer pixels or the screen pixels? Does the monitor's scale factor (as reported by Winit) even match the window's scale factor in this case? If not, trying to create a child window at a certain offset over the parent window using physical pixels may not work right.
• The compositor reports coordinates such that monitors 1 and 2 overlap, though not completely (e.g. use of a projector with different aspect ratio and resolution). If these additionally have different scale factors (thus widths in "physical pixels"), then how do you even calculate the position of the screen to the right/below in physical pixels?

It might make more sense if set_outer_position only supports logical pixels (and notes in the docs that converting from physical pixels might not work as expected).

[dhardy]

The current implementations of MonitorHandle::position, by platform:

• Web, Orbital, Android: always return 0, 0
• Win32: uses the output of GetMonitorInfoW which outputs "A RECT structure that specifies the display monitor rectangle, expressed in virtual-screen coordinates"; Winit directly returns this as a PhysicalPosition which may be incorrect (untested)
• MacOS uses CGDisplayBounds which returns "the bounds of the display, expressed as a rectangle in the global display coordinate space". Winit uses PhysicalPosition::from_logical(..).
• X11 derives monitor info from XRRCrtcInfo. Hard to find docs, but being X11 I think we can assume that units are physical pixels.
• iOS uses nativeBounds, returning "the bounding rectangle of the screen, measured in points." Winit does not do any unit conversion. This may be incorrect?
• Wayland: I'm actually not sure on units. Output is from smithay_client_toolkit::output::OutputInfo::location, which notes "the compositor may decide to always report (0,0) if it decides clients are not allowed to know this information."

Note: MonitorHandle::size mostly does the same thing, though on Wayland it instead iterates through monitor modes to find the current one and returns its dimensions (physical pixels).

@kchibisov given your comments in #2649 I wonder if MonitorHandle::position should simply be removed or revised to return the logical position. I'm unsure whether this also applies to the other APIs mentioned here, WindowEvent::Moved and Window::outer_position.

[kchibisov]

Wayland: I'm actually not sure on units. Output is from smithay_client_toolkit::output::OutputInfo::location, which notes "the compositor may decide to always report (0,0) if it decides clients are not allowed to know this information."

It's not even recommended to use it at all. What should be used is xdg_output, which is compositor logical space. The x and y here have some units.

Could you open a separate issue wrt that. In general I'm not even sure why this could be used, but maybe someone is using these position stuff. I'm just used to Wayland and don't see any uses of such things, because on Wayland everything passes None for wl_output stuff, so compositor picks the right display for you.

[dhardy]

Well, the original issue here is "MonitorHandle::position does not work as expected". The issue we just discussed is "should this method exist at all, and if so what should it actually do". Seems like the same issue to me?

[kchibisov]

Maybe we should rename this issue, since right now it's macOS specific, while our issue is about all the platforms.