WinForms: position and size properties are inconsistent when different screens have different DPIs

[mhsmith]

The current design assumes that all the following properties operate in a single CSS-pixel coordinate system:

• Window.position, Window.size
• Screen.origin, Screen.size

Window.screen_position is then simply defined as Window.position - Screen.origin.

However, it isn't possible to define a consistent CSS-pixel coordinate system that covers different screens with different DPIs. Imagine you have four screens laid out like this:

    -------
    |  1  |
    -------
------- -------
|  2  | |  3  |
------- -------
    -------
    |  4  |
    -------

If screens 2 and 3 have the same physical resolution, but different DPIs, then what is the distance between screens 1 and 4 in CSS pixels? There are two answers, both equally valid.

As discussed in #2155 (comment), our current workaround is:

• Scale all the position/origin properties by the DPI of the primary screen, so they're consistent with each other.
• Scale all the size properties by the DPI of the current screen, so they're consistent with the scaling of the window's content.

So on the primary screen, and any other screen with the same DPI, everything works correctly. But on a screen with a different DPI to the primary one, the position and size properties will be in different scales, so you won’t be able to position windows relative to the bottom or right edges of the screen or of other windows.

I doubt many people are doing things like this, so it's not urgent to fix, but in the future we can implement a proper solution, which I think would look like this:

• Window.position: define to be relative to the current screen's origin and DPI, and move the calculation of that to the backend. Although this is technically backward-incompatible, it’s unlikely that any app will care. Even the "move" commands in examples/window will continue to work; the coordinate system will just change when the window moves onto a different screen.
• Window.screen_position: deprecate, since it's now the same as Window.position.
• Screen.origin: Since there will be no other absolute coordinates in the public API, the only thing an app can do with this information is find out the relative direction of each screen. So the implementation of this property can continue to use the DPI of the primary screen, but the documentation should say that the scale is undefined.

The examples/window app can be used to test this area. Note that the "screen edge" commands are always slightly inaccurate because they don't take the thickness of the title bar and invisible borders into account, but that's not relevant to this issue.

[mhsmith]

Originally posted by @freakboy3742 in #2155 (comment)

---

The "invisible window border" issue you mentioned [is] definitely an oddity, but if the Windows native API considers "window position 0,0" to include space for invisible border elements, then I'm not sure we should be bending over backwards to fix it.

We've discussed the origin/position changes in person, but for the record - I agree that's the general direction we should head. As nice as the idea of "absolute window positioning" is, it clearly doesn't work for the multi-DPI case unless the underlying window system operates entirely in CSS pixels (or any other consistent coordinate space); and given that the use case is pretty eclectic to start with, I'm happy to lose the feature in the name of having a solution that works reliably.