What is the most stable monitor identifier in winit

[ncallaway]

I'd like to make a best-effort to remember the monitor preferences that a user selects in their settings for a project I'm working on.

I'm planning on allowing users to choose between windowed, borderless fullscreen and exclusive fullscreen. When choosing either fullscreen mode, I'd like to ensure that the window appears on a monitor that the user has selected (if it is available).

I'm able to iterate over the connected monitors with the event_loop.available_monitors() iterator. I'm curious which of the following attributes are the most likely to be stable for a user's monitor configuration:

• monitor index (e.g. 0, 1)
• name (e.g "DP-4", "eDP-1")
• native index (e.g. 64, 63)
• fingerprint of video modes (some kind of hash of all available video modes)
• other? (size/position/refresh-rate)

Basically, what attributes are generally the best to persist that I could later use to attempt to try and identify the same monitor the next time my application starts.

[madsmtm]

winit::platform::*::MonitorHandleExt*::native_id is somewhat stable on Linux-like platforms.

Android, Redox and web only support one monitor, so on those you can simply use the primary monitor.

macOS doesn't expose it, but has a way to get a unique ID for a monitor (which it uses in comparisons).

The monitor support on iOS is very spotty, so I doubt it's possible to get a stable identifier for monitors here.

I also can't seem to find any information on the stability of Windows' HMONITOR.

---

It might be possible for us to create a unified API over these (uses the exact ID where possible, a best-effort match on iOS and Windows, and falling back to the primary monitor otherwise), though unsure how exactly that would work.

[ncallaway]

Thanks! That's very helpful!

In my limited testing (just 3 monitors a hash of the video modes) seems to do a decent job at a best effort match of monitors. I'm going to probably use the native_id when it's available, and then fall back to a hash of the video modes as my best effort matching.

If the API you describe did exist, I'd definitely use it, though!